https://www.udemy.com/course/docker-and-kubernetes-the-complete-guide/
docker run hello-world
- ローカルマシンに
hello-world
というimageがなかったらDocker Hubからダウンロードする run
でimageからcontainerを作成する- 2回目以降はローカルマシンのimageが使われるのでDocker Hubへアクセスはしない
- Imageは
File System Snapshot
とStartup Command
から成る - FS Snapshotはコンテナに展開される
-
docker run hello-world
-
imageからcontainerを起動する
-
imageに設定されているStartup Commandが実行される
-
docker run busybox echo hi there
-
docker run busybox ls
-
Startup Commandは新しいコマンドを指定することで上書きできる
-
ただし、そのimageに入っているコマンドのみ実行できる
- 起動中のコンテナを表示
docker run busybox ping google.com
- バックグラウンドでコンテナが動き続けるのでpsで表示される
docker ps --all
- これまでに起動した全てのコンテナが表示される
docker run
=docker create
+docker start
docker create
: imageからcontainerを作成する(FS Snapshotのコピー)docker start
: containerを開始する(Startup Commandの実行)docker create hello-world
-> コンテナIDを返すdocker start -a e4cf8aa
- 終了したコンテナを再起動することができる
- ただし、Startup commandを置き換えることはできない
-a
はattach
コンテナの出力を表示する
- 終了したコンテナやキャッシュを一括削除できる
- コンテナからログを取得する
docker logs e1816dd7ba
- 終了してしまったコンテナIDでもOK
docker stop
はプロセスに対してSIGTERMシグナルを送る- クリーンアップ処理が入るので終了まで少し時間がかかる
docker kill
はプロセスに対してSIGKILLシグナルを送る- 強制終了させる
- コンテナで「追加の」コマンドを実行する
docker run redis
コンテナでredisサーバを起動docker exec -it 0affbcc28d4e redis-cli
- 上のコンテナでコマンドを実行する
-i
ターミナルの入力をコンテナのstdinへつなげる-t
コンテナのstdoutとstderrをターミナルへつなげる
docker exec -it 0affbcc28d4e sh
- デバッグに便利!
- shはだいたい内蔵している、bashやzshが使えるコンテナも
docker run -it busybox sh
- コンテナの起動時にshellを実行したいとき
独自NodeアプリのimageをDockerで作成する。
オリジナルのimageのテンプレートになる
- ベースイメージを指定する
- 追加のプログラムをインストールする
- コンテナを開始した時のStartup commandを定義する
- Dockerfileからimageをbuildする
docker build .
Dockerfile
FROM alpine
RUN apk add --update redis
CMD ["redis-server"]
- 各ステップにおいて前のimageの一時的なコンテナを作成してコマンドを実行する
- 各ステップの最後で一時的なコンテナは削除して新しいimageを作る
Step 2/3 : RUN apk add --update redis
---> Running in 586d9af2f84e # 一時的なコンテナを作成
Removing intermediate container 586d9af2f84e # 一時的なコンテナを削除
---> 2d406a836250 # 新しいimageを作成
Step 3/3 : CMD ["redis-server"]
---> Running in ea3c5a296c49 # 一時的なコンテナを作成
Removing intermediate container ea3c5a296c49 # 一時的なコンテナを削除
---> d037ccca4765 # 新しいimageを作成
Successfully built d037ccca4765
- imageにタグをつけると後から参照しやすい
docker build -t f2forest/redis:latest .
- コンテナからimageを作成する
- コンテナの中に入って作業した後にオリジナルimageを作る時に使う
docker commit -c 'CMD ["redis-server"]' 32a278410a10 myimage:latest
- コンテナ起動時に実行するコマンドは
-c
で指定できる
Node.jsのアプリケーションをDockerで動かす
node:alpine
などalpineがついているバージョンは余計なツールが付属していない最小イメージを意味する
- package.jsonは事前に転送が必要
npm install
を動かすためにpackage.json
が必要なのでローカルからコンテナへCOPYするCOPY . .
でローカルファイル(package.json)をコンテナにコピー.
はdocker build
で指定したコンテキストからの相対パス- キャッシュを有効的に使うために先に
package.json
だけ転送し、ビルドした後に残りのファイルを転送するとよい
WORKDIR /usr/app
COPY ./package.json ./
RUN npm install
COPY ./ ./
- ローカルマシンからコンテナの8080ポートにそのままではアクセスできない
- docker runでPort Mappingを使う
docker run -p 8080:8080 <image_id>
- ローカルマシンの8080:コンテナの8080
- alpineのデフォルトではCOPYで
/
にファイルが転送される - 事前にWorking Directoryを指定しておくとよい
WORKDIR /usr/app
FROM node:alpine
WORKDIR /usr/app
COPY ./package.json ./
RUN npm install
COPY ./ ./
CMD ["npm", "start"]
- NodeアプリとRedisを異なるコンテナで実行する。
- デフォルトではコンテナ間の通信はできない
- Docker CLIのネットワーク機能を使う
- Docker Composeを使う(おすすめ)
- Dockerとは別のツール
- 複数のDockerコンテナを同時に起動できる
- docker runに指定する必要がある複雑な引数を自動化できる
- コンテナ間の通信も簡単にできる
- 複数のコンテナの設定を記述するファイル
version: "3"
services:
redis-server:
image: "redis"
node-app:
build: .
ports:
- "4001:8081"
- docker-compose.ymlで書いたサービスは同一のネットワークに所属して互いにアクセス可能に
- アプリケーションからはservicesの名前でホストにアクセスできる
const client = redis.createClient({
host: "redis-server",
port: 6379
});
-
全てのコンテナを起動する
docker-compose up
-
コンテナをbuildしてから起動する
docker-compose up --build
-
コンテナをバックグラウンドで起動する
docker-compose up -d
-
全てのコンテナを停止する
docker-compose down
- アプリケーションがcrashするとコンテナごと落ちてしまう
version: "3"
services:
redis-server:
image: "redis"
node-app:
restart: always
build: .
ports:
- "4001:8081"
- "no": リスタートしない(予約語なので""が必要)
- always: いつもリスタートする
- on-failure: エラーコード(0以外)が返った時のみリスタート
- unless-stopped: 開発者が強制終了しない限りリスタート
- コンテナのプロセスを確認する
docker-compose.yml
があるディレクトリのみ表示される
- ローカルマシンで開発
- Githubのfeature branchにpush
- PRを出してmasterにmerge
- Travis CIにpushしてテスト
- Travis CIがAWS (Elastic Beanstalk) にデプロイ
DockerはこれらのFlowを簡単化するツールとして使われる。
npm install -g create-react-app
create-react-app client
よりも
npx create-react-app client
がよい
npm run start
: development serverを起動npm run test
: テストを実行npm run build
: production versionをbuild
development用のDockerfileを作るとよい
FROM node:alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["npm", "run", "start"]
Dockerfile
以外の名前の時は-f
オプションを使うdocker build -f Dockerfile.dev .
COPY . .
するとローカルのnode_modules
を転送してしまうのであらかじめ削除しておくこと!- コンテナ内の
npm install
でnode_modules
ができる docker run -p 3000:3000 86a212
でReact Appを起動できる(port指定を忘れないこと!)
- ローカルのソースの編集がコンテナのアプリに反映されない問題がある
- ローカルのファイルをCOPYするのではなく、コンテナがローカルのファイルを参照するようにする仕組みがDocker Volumes
docker run -p 3000:3000 -v /app/node_modules -v $(pwd):/app 86a212
-v
オプションは:
を使う構文と使わない構文があるので注意!-v $(pwd):/app
ローカルのカレントディレクトリをコンテナの/app
にマッピング- ローカルカレントディレクトリをマッピングすると、
node_modules
がないという問題がある - コンテナにのみある
node_modules
をそのまま残したい場合に-v /app/node_modules
を使う :
なしのオプションは コンテナにあるファイル を指定する- volumeを使う場合は、
COPY . .
のファイルコピーは不要だが 残しておいたほうがよい
docker run
のコマンドが長くなりがち => docker-composeで解決できる!- コンテナが1つでもdocker-composeは使える
- デフォルトの
Dockerfile
以外を使う場合はcontext
とdockerfile
を指定する
version: "3"
services:
web:
build:
context: .
dockerfile: Dockerfile.dev
ports:
- "3000:3000"
volumes:
- /app/node_modules
- .:/app
- Dockerfileのデフォルトコマンドは
npm run start
になっている docker run -it fe1a37cb8148 npm run test
コマンドを置き換えれば、同じコンテナでtestを起動できる
上の方法ではvolumeを使ってないため src/App.test.js
を更新しても反映されない問題がある
docker-compose up
でボリュームをしたコンテナを起動する- そのコンテナでテストを実行する
docker exec -it ed9c9c1bc87a npm run test
で解決できるが、 docker exec
のコマンドを実行するのは負荷が高い
docker-compose.yml
に新しいコンテナを追加するアプローチもある。ただし、この方法はテストのキーボード入力が使えない & webのロギングと混ざるという欠点がある。
version: "3"
services:
web:
build:
context: .
dockerfile: Dockerfile.dev
ports:
- "3000:3000"
volumes:
- /app/node_modules
- .:/app
tests:
build:
context: .
dockerfile: Dockerfile.dev
volumes:
- /app/node_modules
- .:/app
command: ["npm", "run", "test"]
- 結局、webコンテナの中に入って
npm run test
やったほうが早いんじゃ・・・? - インタラクティブにコマンド入力もできる
- 開発環境で
index.html
やmain.js
を提供するのに使っていたDevelopment Serverは、製品環境では使えない - Development Serverの代わりになるProduction Serverである nginx が必要
製品環境用に Dockerfile
を新しく作る
- Use node:alpine
- Copy the package.json file
- Install dependencies => これは
npm run build
をするためだけに必要(deployには不要、build
だけあればOK) - Run
npm run build
- Start nginx =>
nginx
はどこにある???
この問題を解決するのが Multi-step Docker Builds
- Use node:alpine
- Copy the package.json file
- Install dependencies
- Run
npm run build
- Use nginx
- Copy over the result of
npm run build
- Start nginx
- 複数のstageを1つのDockerfileの中に書ける
as
でstageに名前をつけられるCOPY --from=XXX
で別のstageのファイルをコピーできる
FROM node:alpine as builder
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run biild
FROM nginx
COPY --from=builder /app/build /usr/share/nginx/html
- nginxのstaticファイルは
/usr/share/nginx/html
に置く - nginxはRUNは不要、ファイルをコピーするだけで動く
docker run -p 8080:80 656571ea6184
- この節の最終リポジトリ https://github.com/aidiary/docker-react
- Travis CIは、Githubからリポジトリを取得して、テストしたり、AWSへデプロイしたりできる
- Profileをクリックして
Legacy Services Integration
から対象のリポジトリをチェック - リポジトリに
.travis.yml
(Travisが何をするかを記述した設定ファイル)を作成
sudo: required
services:
- docker
before_install:
- docker build -t f2forest/docker-react -f Dockerfile.dev .
script:
- docker run -e CI=true f2forest/docker-react npm run test
- dockerはsudoで実行なので
sudo: required
が必要 npm run test
はプロンプトを出すので正常終了しない-e CI=true
を付ける- GithubにpushするとTravis CIが動き出す
The command "docker run -e CI=true f2forest/docker-react npm run test" exited with 0.
Done. Your build exited with 0.
になっていればテストが通った状態。
- https://www.youtube.com/watch?v=lBu7Ov3Rt-M&feature=youtu.be
- https://www.youtube.com/watch?v=pLw6MLqwmew&feature=youtu.be
- アプリケーションの作成
- アプリケーションの環境を作成
- ウェブサーバー環境の作成
- プラットフォーム
Docker
にして環境作成 - ヘルスOKでURLにアクセスできれば成功
- Elastic Beanstalkを起動するとLoad Balancerも作られる
- リクエストがLoad Balancernに届くと、Appが動くDocker Containerに振り分ける
- 負荷に応じて自動的にスケールする(Containerが複数起動する)
- IAMの
Users
でdocker-react-travis-ci
(任意)を作成してProgrammatic access
にチェック Attach existing policies directly
でAWSElasticBeanstalkFullAccess
をチェック- 作成時に表示されるSecret access keyへはあとでアクセスできないのでCSVを保存しておくこと
sudo: required
services:
- docker
before_install:
- docker build -t f2forest/docker-react -f Dockerfile.dev .
script:
- docker run -e CI=true f2forest/docker-react npm run test
deploy:
provider: elasticbeanstalk
region: "us-east-2"
app: "docker-react"
env: "DockerReact-env"
bucket_name: "elasticbeanstalk-us-east-2-189406403391"
bucket_path: "docker-react"
on:
branch: master
access_key_id: $AWS_ACCESS_KEY
secret_access_key:
source: "$AWS_SECRET_KEY"
- 本番環境のビルドはElastic Beanstalk側でやっている?
- アプリに必要なファイルはTravis CIがS3へアップロードする
- Elastic BeanstalkのS3は自動的に作られる
elasticbeanstalk-us-east-2-189406403391
bucket_path
は最初にデプロイした時に自動的に作られるmaster
にmergeされた時のみデプロイする- Travisの
More Options > Settings > Environment Variables
にAWSのキーAWS_ACCESS_KEY
とAWS_SECRET_KEY
を保存 - production環境のビルドのコマンドは不要? Dockerfileを自動的に使うようだ
- AWS Elastic Beanstalkで動かすときは
EXPOSE 80
の追加が必要
FROM nginx
EXPOSE 80
COPY --from=builder /app/build /usr/share/nginx/html
Fibonacci Calculatorを作る。 以下の複数のコンテナから成る。
- Nginx: リクエストを受け付けるWebサーバ
- React App: FrontendのGUIアプリ
- Express Server: Fibonacci数を計算するbackendのAPI
- Postgres: ユーザの入力したindexを永続的に保存
- Redis: indexと計算したFibonacci数のペアを保存
- Worker: Redisに新しいindexが入ったか監視し、Fibonacci数を計算して返す
nodemon
は、開発環境でサーバを自動起動させるためのライブラリ- Fibonacciの再帰計算は遅いので、計算を担当するWorkerとして独立させる
keys.js
というファイルを作って環境変数はまとめておくと便利- 環境変数はdocker-composeで指定できる
module.exports = {
redisHost: process.env.REDIS_HOST,
redisPort: process.env.REDIS_PORT,
pgUser: process.env.PGUSER,
pgHost: process.env.PGHOST,
pgDatabase: process.env.PGDATABASE,
pgPassword: process.env.PGPASSWORD,
pgPort: process.env.PGPORT
};
- React App
FROM node:alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["npm", "run", "start"]
- Express Server
npm run dev
でnodemonが起動するようにpackage.json
を設定
FROM node:alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["npm", "run", "dev"]
- 複数のDockerコンテナやDBを束ねるためのdocker-composeを構成
- Express Serverとredis/postgresはserverの環境変数で結び付く
variableName=value
は、ランタイム(コンテナをrunしたとき)でセットするvariableName
は、ランタイムでローカルマシンの環境変数から取られる(API_KEYなど)- HOST名は
http://
を付けずに単にservice名を指定すればOK depends_on
がないと正常に動かないことがある- https://docs.docker.com/compose/compose-file/#depends_on
version: "3"
services:
postgres:
image: "postgres:latest"
redis:
image: "redis:latest"
nginx:
restart: always
build:
dockerfile: Dockerfile.dev
context: ./nginx
ports:
- '8080:80'
depends_on:
- api
- client
api: # Express Server
build:
dockerfile: Dockerfile.dev
context: ./server
volumes:
- /app/node_modules
- ./server:/app
environment:
- REDIS_HOST=redis
- REDIS_PORT=6379
- PGUSER=postgres
- PGHOST=postgres
- PGDATABASE=postgres
- PGPASSWORD=postgres_password
- PGPORT=5432
depends_on:
- postgres
client: # React App
build:
dockerfile: Dockerfile.dev
context: ./client
volumes:
- /app/node_modules
- ./client:/app
worker:
build:
dockerfile: Dockerfile.dev
context: ./worker
volumes:
- /app/node_modules
- ./worker:/app
environment:
- REDIS_HOST=redis
- REDIS_PORT=6379
- NginxはURLを見て React App と Express Server を切り替える役割がある
/index.html
,/main.js
====> React App/values/all
,/values/current
====> Express Server- Express Serverは
/values/all
/values/current
など記述 - React Appは
/api/values/all
/api/values/current
など/api/
を付けてアクセス - Nginxは
/api/
が付いていたらExpress Serverへ、/
だったらReact Appへ流す - Nginxは
/api/
を省いた残りをExpress Serverへ送る
- Nginxの設定ファイル
- React Appは3000でlisten
- Express Serverは5000でlisten
- Nginxは80でlisten
rewrite /api/(.*) /$1 break;
によってExpress Serverへは/api/
を除いたURLが送られる- default.confは セミコロンを忘れずに!
upstream client {
# clientはReact AppのHOST名 @ docker-compose.yml
server client:3000;
}
upstream api {
# apiはExpress ServerのHOST名 @ docker-compose.yml
server api:5000;
}
server {
listen 80;
location / {
proxy_pass http://client;
}
location /api {
rewrite /api/(.*) /$1 break;
proxy_pass http://api;
}
}
FROM nginx
COPY ./default.conf /etc/nginx/conf.d/default.conf
docker-compose.yml
にも追加
services:
nginx:
restart: always
build:
dockerfile: Dockerfile.dev
context: ./nginx
ports:
- '8080:80'
depends_on:
- api
- client
- Chrome devtoolsで以下のWarningが出ることがある。
- React.jsが開発時に使っている
websocket.js:6 WebSocket connection to 'ws://localhost:8080/sockjs-node/273/5leumlyb/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400
- Nginxの設定で
/sockjs-node
をReact Appへ接続する必要がある
location /sockjs-node {
proxy_pass http://client;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
TravisCIを経由してAWSのElastic Beanstalkへデプロイするまで
- Push code to github
- Travis automatically pulls repo
- Travis builds a test image, test code
- Travis builds prod images
- Travis pushes built prod images to Docker Hub
- Travis pushes project to AWS EB
- EB pulls images from Docker Hub, deploys
- オリジナルのimageとnginx/postgres/redisなど既存imageが混ざった状況
- オリジナルのimageはDocker Hubに登録できるので活用するとデプロイが容易に
- TravisCIでアプリをビルドしてDocker HubにアップロードしておけばElastic Beanstalkでビルドが不要になる
- worker/serverに関しては
npm run dev
をnpm run start
に置き換えるだけ package.json
でnode index.js
が指定されている
FROM node:alpine
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
CMD ["npm", "run", "start"]
- clientはReact Appなのでビルドが必要
- Routingを担当するNginxと、ビルドしたReactAppを提供するNginxの2つを用意する
- clientのNginxは3000ポートにアクセスされた時にビルドしたReactAppを提供する
client/nginx/default.conf
server {
listen 3000;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
try_files $uri $uri/ /index.html;
}
}
client/Dockerfile
FROM node:alpine as builder
WORKDIR /app
COPY package.json .
RUN npm install
COPY . .
RUN npm run build
FROM nginx
EXPOSE 3000
COPY ./nginx/default.conf /etc/nginx/conf.d/default.conf
COPY --from=builder /app/build /usr/share/nginx/html
- React Appのテスト
- imageのビルド
- Docker Hubへimageをpush
.travis.yml
sudo: required
services:
- docker
before_install:
# build image for test
- docker build -t f2forest/react-test -f ./client/Dockerfile.dev ./client
script:
# run test
- docker run -e CI=true f2forest/react-test npm run test
after_success:
# build image
- docker build -t f2forest/multi-client ./client
- docker build -t f2forest/multi-nginx ./nginx
- docker build -t f2forest/multi-server ./server
- docker build -t f2forest/multi-worker ./worker
# Log in to the docker CLI
# ユーザ名とパスワードは見えないようにTravis CIの環境変数に登録しておく
- echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_ID" --password-stdin
# Take those images and push them to docker hub
- docker push f2forest/multi-client
- docker push f2forest/multi-nginx
- docker push f2forest/multi-server
- docker push f2forest/multi-worker
- 単一コンテナの場合は、Elastic BeanstalkがDockerfileから自動的にビルドしてデプロイしていた
- 複数コンテナ(複数のDockerfile)からなる場合は、追加の設定
Dockerrun.aws.json
が必要 - docker-compose.ymlと違ってすでにbuildされたimageを設定する
- ECS (Elastic Container Service) の task definition と仕様がほとんど同じなのでドキュメントが参考になる
- https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/task_definitions.html
essential: true
は対象コンテナが落ちたら他のコンテナも落ちるようにする設定- nginxが落ちると他のコンテナへはアクセスできなくなるのでessentialにする
- Dockerrun.aws.jsonでのタイポは厄介なので https://jsonlint.com/ などで確認するとよい
{
"AWSEBDockerrunVersion": 2,
"containerDefinitions": [
{
"name": "client",
"image": "f2forest/multi-client",
"hostname": "client",
"essential": false
},
{
"name": "server",
"image": "f2forest/multi-server",
"hostname": "api",
"essential": false
},
{
"name": "worker",
"image": "f2forest/multi-worker",
"hostname": "worker",
"essential": false
},
{
"name": "nginx",
"image": "f2forest/multi-nginx",
"hostname": "nginx",
"essential": true,
"portMappings": [
{
"hostPort": 80,
"containerPort": 80
}
],
"links": ["client", "server"]
}
]
}
- Platformに
Multi-container Docker
を指定 - あとはデフォルトで環境を作成
- Redisは
AWS Elastic Cache
に置き換えるとよい - Postgresは
AWS Relational Database Service
に置き換えるとよい
https://aws.amazon.com/jp/elasticache/
- Redisインスタンスを自動的に作成してくれる
- スケールが簡単
- ロギングやメンテナンスがしやすい
- 強固なセキュリティ
- AWS以外のサービスへの移植が簡単
https://aws.amazon.com/jp/rds/
- Postgresインスタンスを自動的に作成してくれる
- スケールが簡単
- ロギングやメンテナンスがしやすい
- 強固なセキュリティ
- 自動バックアップとロールバック
- AWS以外のサービスへの移植が簡単
- デフォルトでは、Elastic BeanstalkからRDSやECにアクセスできない
- 同じ VPC (Virtual Private Cloud) にEB/RDS/ECをまとめる
- VPCはRegionをまたぐことはできない
- Security Group (Firewall Rules)
- Elastic Beanstalkの環境を作るとVPCとSecurity Groupsができている (?)
- 同じセキュリティグループに属するAWSサービスからの接続を許可するようにEB/RDS/ECを設定
- データベースの作成でPostgresSQLを選択
- テストなので
db.t2.micro
を選択 - DBインスタンス識別子:
multi-docker-postgres
- Master username:
postgres
- Master password:
postgres_password
- VPCセキュリティグループ:
新規作成
>multi-docker
- 最初のデータベース名:
fibvalues
- Redisで作成
- 名前:
multi-docker-redis
- ノードのタイプ:
t2.micro
- サブネットグループの名前:
redis-group
- VPC ID: EBで作られたVPC
- 名前:
multi-docker
- インバウンドルール: カスタムTCP 5432-6379
- 5432は
PGPORT
、6379はREDIS_PORT
- ソース: multi-dockerのsg
- EB/RDS/ECをこのSecurity Groupに所属させる!
- Redisにアクセスできないエラー(Timeout)があったが、Security Group追加してないためだった。要注意!
- EBからRedisやRDSへアクセスするための設定
EB > 設定 > ソフトウェア
から環境変数を設定する- redis/postgresのエンドポイントのURLはAWSのサービスから取得できる
- REDIS_HOST=multi-docker-redis.yf6uwv.0001.use1.cache.amazonaws.com
- REDIS_PORT=6379
- PGUSER=postgres
- PGHOST=multi-docker-postgres.cfyostac2ypt.us-east-1.rds.amazonaws.com
- PGDATABASE=fibvalues
- PGPASSWORD=postgres_password
- PGPORT=5432
- Travis CIからAWSへアクセスするためのkeyを取得
- ユーザを作成してアクセスキーIDとシークレットアクセスキーを取得
- Travis CIの環境変数に
AWS_ACCESS_KEY
とAWS_SECRET_KEY
を追加
- Travis CIからAWSにdeployする設定を追加
deploy:
provider: elasticbeanstalk
region: us-east-1
app: multi-docker
env: MultiDocker-env
bucket_name: elasticbeanstalk-us-east-1-189406403391
bucket_path: multi-docker
on:
branch: master
access_key_id: $AWS_ACCESS_KEY
secret_access_key: $AWS_SECRET_KEY
- GithubにpushしてTravis CIからデプロイするとElastic Beanstalkで以下のエラー
Service:AmazonECS, Code:ClientException, Message:Invalid setting for container 'client'. At least one of 'memory' or 'memoryReservation' must be specified., Class:com.amazonaws.services.ecs.model.ClientException
Dockerrun.aws.json
にmemory
を追加