build実行時にオプション --build-arg として渡せる可変の値
環境毎になにかを変える時に使用する
など
ARG hoge="fuga"
上記は、変数 hoge を時環境変数 HOGE に定義している
ARG 変数名 で変数を定義する。ここで定義しない変数は使用できないARG 変数名=デフォルト値 でデフォルト値も定義可能ENV HOGE=$hoge
$変数名 で変数展開される
ARG に値を渡す方法$ docker build . --build-arg hoge=fuga
build-arg を定義する方法build の args に定義する
app:
build:
args:
hoge: fuga
そんなかんじ
これの続編
インスタンスの管理が不要な Amazon Aurora
決して、serverless 専用の Aurora ではない
インスタンスの管理が不要なため、Auroraよりも更に運用コストが低下している
上記のスケーラブルのために、負荷が不安定だったり、決められた時間にしか使用しないサーバなどはAmazon Aurora serverlessでコストダウンできる
👆初回接続に22秒かかることを確認している
👆ACU毎の最大コネクション数の調査
👆「スケールアップまたはスケールダウンは数秒で行われる一方、最初のインスタンスへの接続は25秒前後のレイテンシがあると説明されています」
👆一時停止→復帰、スケールが生じるとバッファプール（バッファキャッシュ）が初期化されるとのこと
24/365で高負荷なサービスで運用するのには難しそう
ユースケースにあるとおり、低頻度利用環境向けのサービスと見るのが良さそう
DBのパスワードとかの機密情報をECSのtask実行時の環境変数に入れたい場合、AWS Systems Manager パラメータストアを使うとかんたん&安全
AWS Systems Manager パラメータストア は､設定データ管理と機密管理のための安全な階層型ストレージを提供します。パスワード、データベース文字列、ライセンスコードなどのデータをパラメータ値として保存することができます。値はプレーンテキストまたは暗号化されたデータとして保存できます。
環境変数とかにパスワードとか入れたい時に便利!
AWSで機密情報を扱いたい時にはどちらかを使えと公式ドキュメントにかかれている
Amazon ECS を使用すると、AWS Secrets Manager シークレットまたは AWS Systems Manager パラメータストアのパラメータに機密データを保存してコンテナの定義でそれを参照することによって、コンテナに機密データを挿入できます。
こちらを参照しながら決めると良いかも
AWS Systems Manager のパラメータストアで、1 秒間に最大 1,000 件のリクエストがサポートされるようになりました。これにより、多数のパラメータに対してより高い同時アクセスが必要なアプリケーションを実行できるようになります
AWS Systems Manager がより高い API スループットでのパラメーターストアの使用のサポートを開始
ひとまずはAWS Systems Manager パラメータストアを使って、困ったらSecrets Managerに移行することにした
ECSを実行するロールに以下の権限を追加する
"ssm:GetParameters",
"kms:Decrypt"
自分の場合、今まで使用していたECS実行用のロールにインラインポリシーとしてアタッチした
(厳密にやるなら、アクセスできる機密情報の範囲をResourceで指定すること)
AWS System Manager -> パラメータストア -> パラメータの作成 で設定できる
「安全な文字列」にしないと、暗号化されないので注意
よそのアカウントのKMSキーを使いたい場合は、「別のアカウント」にする
"containerDefinitions": [
{
"secrets": [
{
"name": "DATABASE_USERNAME",
"valueFrom": "arn:aws:ssm:us-east-1:*********:parameter/DATABASE_USERNAME"
},
{
"name": "DATABASE_PASSWORD",
"valueFrom": "arn:aws:ssm:us-east-1:*********:parameter/DATABASE_PASSWORD"
}
],
以上で、task実行時に環境変数に機密情報が格納されます!! 便利 & かんたん!!
dockerfileの CMD や ENTRYPOINT でコマンドを定義する方法は2通りある
["echo", "${HOGE}"]
"echo ${HOGE}"
/bin/sh -c を介してコマンドが実行される(変数展開が行われる )なので、CMD や ENTRYPOINT で変数展開したい場合、shell form を使用すればよい
exeform の中で shell を呼び出せば良い
ENTRYPOINT ["/bin/sh", "-c", "echo ${HOGE}"]
以下のように定義すると、HOGE は出力されず、空文字が出力される
ENTRYPOINT ["/bin/sh", "-c", "echo", "${HOGE}"]
これは、${HOGE} が、echo ではなく、/bin/sh の第二引数に渡るため
(第二引数は特に何もしない)
きちんと理解したら全然意味が異なるものだった
docker run 時に実行されるコマンドを定義
apacheを起動させるコンテナ(オフィシャルじゃないけど、説明に最適だった) の ENTRYPOINT
ENTRYPOINT ["/usr/sbin/apache2"]
docker run した場合 /usr/sbin/apache2 が実行される
--entrypoint オプションで変更可能これがあるコンテナは、apacheのコンテナの様に単一の用途を持つという印象
docker run 時のコンテナのデフォルトを定義
この、「デフォルト」は2つの意味がある
docker run 時の ENTRYPOINT の デフォルトの引数docker run 時に デフォルトで実行されるコマンドENTRYPOINT のデフォルトの引数apache のコンテナ の CMD
CMD ["-D", "FOREGROUND"]
docker run した場合 ENTRYPOINT と合わせて /usr/sbin/apache2 -D FOREGROUND が実行される
もし、docker run に引数を与えた場合、CMD で定義された部分だけが置き換えられる
例えば、docker run -v を実行した場合、コンテナ上では /usr/sbin/apache2 -v が実行される
alpine linuxのコンテナ の CMD
CMD ["/bin/sh"]
なので、
docker run -it とすれば、シェルに入ることができるし、docker run -it echo "hello" とかすれば、任意のコマンドを実行できるENTRYPOINT は docker run 時に実行されるコマンドを定めるCMD は docker run 時のデフォルトを定める。デフォルトとは
ENTRYPOINT のデフォルトの引数ENTRYPOINT と CMD 両方が実行可能な場合、CMD は無視される様子
FROM ubuntu:latest ENTRYPOINT ["/bin/sh", "-c", "echo 123"] CMD ["/bin/sh", "-c", "echo aaaa"]
これを docker run すると、123 が出力される
メジャーなコンテナのDockerfileを見たけど、CMD 単一定義のものも多いので、そこまで厳密に定めなくても良いような気もしてきた
heroku.yml の設定を間違えたりすると、デプロイ後、以下のエラーが出てタイムアウトするまで待たされて困るので、キャンセル方法を調べた
remote: Compressing source files... done. remote: Building source: remote: === Fetching app code remote: remote: =!= Unknown error
heroku builds プラグインをインストール後、以下のコマンドを実行
heroku builds:cancel --app ${app_name}
heroku plugins:install heroku-builds
セキュリティ上の理由等で、普段管理画面上でロールの切り替えを行っているけれど、それをCLI上でやる場合どうするの?
ロール切り替え用のprofileを設定して、それを指定してあげれば良い
~/.aws/config
[default] output = json region = ap-northeast-1 [profile adminrole] source_profile = default role_arn = arn:aws:iam::***:role/AdminRole region = ap-northeast-1
profile adminrole が、ロール切り替え後のprofile。 role_arn に切り替え先のロールを設定する
default の場合$ aws sts get-caller-identity --profile default
{
"UserId": "********",
"Account": "*********",
"Arn": "arn:aws:iam::********:user/lcl-kobayashi"
}
arn が、IAMユーザであることがわかる
adminrole の場合$ aws sts get-caller-identity --profile adminrole
{
"UserId": "********:botocore-session-********",
"Account": "********",
"Arn": "arn:aws:sts::********:assumed-role/AdminRole/botocore-session-********"
}
adminrole のprofile の場合、Arnが、IAMロールに変わっている
adminrole を --profile なしで使用したい場合環境変数 AWS_PROFILE を使用する
export AWS_PROFILE=adminrole