Macの環境 機種:MacBook Air(M1,2020) CPU:Apple M1 Memory:16Gb OS:macOS Big Sur SHELL:zsh docker:20.10.8 CUI tab補完 docker公式のコマンドライン補完の設定はcurlのリンクが死んでいて利用できなかった。そのため、dockerをインストールした際に存在している補完ソースを利用した。今回は、自身の環境で成功した、zshについて書く。 zsh-completionsの確認 zsh-completionsを使うため、インストールされているか確認する。 $ brew list | grep zsh-completions # 存在していなければ、下記を実行 $ brew install zsh-completions 補完ソースのシンボリックリンクを作成 # ~/.zsh/completionsの階層がなければ、下記を実行 $ mkdir -p ~/.zsh/completions # 補完ソースの保存場所作成 $ touch _docker $ touch _docker-compose $ ln -s /Applications/Docker.app/Contents/Resources/etc/docker.zsh-completion ~/.zsh/completions/_docker $ ln -s /Applications/Docker.app/Contents/Resources/etc/docker-compose.zsh-completion ~/.zsh/completions/_docker-compose zsh-completionsの有効化 .zshrc # 下記の追記 fpath=(~/.zsh/completion $fpath) autoload -Uz compinit && compinit -i zshの再起動 $ source ~/.zshrc

この記事の内容 Dockerでnginxを使用する際に気をつけたポイントについて書いてみた。 他コンテナとの連携方法や、nginxの設定などについて触れる。 サンプルコード 本記事で解説したコードを公開しています。 https://github.com/fukky21/nginx-sample 全体の構成 今回は以下のような構成を考えてみる。 環境構築 docker-compose.yml version: '3.9' services: proxy: image: nginx:1.21.0 container_name: nginx-sample_proxy volumes: - ./proxy/nginx.conf:/etc/nginx/nginx.conf - ./proxy/html:/etc/nginx/html - ./proxy/log:/var/log/nginx ports: - '80:80' depends_on: - api - web api: build: context: ./api dockerfile: Dockerfile container_name: nginx-sample_api command: yarn dev volumes: - ./api:/app tty: true web: build: context: ./web dockerfile: Dockerfile container_name: nginx-sample_web command: yarn dev volumes: - ./web:/app tty: true environment: PORT: 3000 HOST: 0.0.0.0 いくつかポイントがあるので解説する。 Dockerfileの内容については、サンプルコードをご覧ください。 proxyの起動を最後にする depends_onでwebとapiを指定することで、proxyよりも先にその2つが起動する。 nginx.confで、プロキシの転送先にnginx-sample_apiとnginx-sample_webを指定するので、最後に起動する必要がある。 webとapiのポートをホスト側に公開しない webとapiにはportsを指定しない。こうすることで、ホストから直接webとapiにアクセスすることはできず、必ずproxyを経由することになる。 webの環境変数にPORTとHOSTを指定する webのenvironmentでPORTとHOSTを指定している。 これを指定しないと502 Bad Gatewayと表示され、Webサイト(Nuxt.js)に接続できない。 原因に関しては、この記事に分かりやすくまとめられている。 https://qiita.com/amuyikam/items/01a8c16e3ddbcc734a46 container_nameを指定する 後ほど紹介するnginx.confで、ここで指定したcontainer_nameを使用する。 nginxの設定 nginx.conf worker_processes auto; events { worker_connections 16; } http { server { listen 80 default_server; server_name _; return 444; } server { listen 80; server_name localhost; proxy_redirect off; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Connection ''; error_page 404 /404.html; location = /404.html { root /etc/nginx/html; internal; } location /app/ { allow 172.24.0.1; deny all; proxy_pass http://nginx-sample_web:3000; } location /api/ { proxy_pass http://nginx-sample_api:3080; } } } worker_processesとworker_connections こちらの記事によると、 nginxにおける同時クライアントの最大数は、worker_processes × worker_connectionsの数で決まる。 ということらしい。 worker_processes autoとすると、ワーカープロセス数はCPUのコア数と同じになる。 Macの場合、CPUコア数は下のコマンドで確認できる。 $ system_profiler SPHardwareDataType | awk '/Total Number of Cores/ { print $NF }' worker_connectionsの値を色々いじってみると、接続できるクライアント数が変わることを確認できる。 IPの直打ちアクセスを弾く server { listen 80 default_server; server_name _; return 444; } http://127.0.0.1/app のように、IPアドレスを直打ちしてアクセスしてきた場合に接続を切ることで、攻撃を防ぐことができる。 444は、接続を閉じるためのnginxの特別な標準外コードで、詳しくはこちらを参照。 ヘッダーを書き換える proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Server $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Connection ''; ヘッダーの書き換えを行わない場合、webやapi側にはプロキシからリクエストが来たことしか伝わらない。ヘッダー情報を、プロキシにアクセスしてきたクライアントの情報に書き換えることで、webやapi側でもクライアントの情報を扱えるようになる。 エラーページをカスタマイズする error_page 404 /404.html; location = /404.html { root /etc/nginx/html; internal; } デフォルトのエラーページでは以下のように表示される。 nginxを使用していることがクライアントにバレてしまうのが嫌な場合は、エラーページを独自に設定すると良い。 今回の例では、404(Not Found)のときだけオリジナルのエラーページが表示されるようにしてあるが、403(Forbidden)や500(Internal Server Error)のときも個別に指定できる。 internalを指定することで、内部からのリクエストのためだけに使用されることになり、外部からは直接アクセスできなくなる。 IPアドレス制限をかける allow 172.24.0.1; deny all; 管理者サイトなど、特定のIPアドレスからのアクセスのみ許可したい場合はallowで指定する。その後ろにdeny allを記述することで、allowで指定したIPアドレス以外のアクセスを弾くことができる。

DynamoDB の Docker イメージが公式から提供されていたので、このイメージを使用してローカルに DynamoDB をデプロイしてみます。さらに、ローカルに構築した DynamoDB にデータをインサートしてテーブルの中身を確認するところまでやってみたいと思います。 Docker で DynamoDB を構築 docker-compose.yamlを用意して、次の内容をファイルにコピーして保存します。 docker-compose.yaml version: '3.8' services: dynamodb-local: command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ./data" image: "amazon/dynamodb-local:latest" container_name: dynamodb-local ports: - "8000:8000" volumes: - "./docker/dynamodb:/home/dynamodblocal/data" working_dir: /home/dynamodblocal コンテナを立ち上げます。 docker-compose up -d DynamoDB Local の構築は以上で終わりです。さすが Docker といった感じでとても簡単です。 サンプル: データをインサートする ローカルに DynamoDB が構築できたら、実際にデータを登録してみます。まずは、テーブルを作成します。 aws dynamodb create-table \ --region ap-northeast-1 \ --endpoint-url http://localhost:8000 \ --table-name animals \ --key-schema AttributeName=id,KeyType=HASH \ --attribute-definitions AttributeName=id,AttributeType=S \ --billing-mode PAY_PER_REQUEST テーブルが作成できたか、list-tables コマンドを使って確認します。 $ aws dynamodb list-tables --endpoint-url http://localhost:8000 { "TableNames": [ "animals" ] } テーブルが作成できたら、データをインサートしてみます。今回は、AWS SDK for JavaScript v3を使ってデータを登録してみます。 まずは、必要なモジュールをインストールします。 npm install @aws-sdk/client-dynamodb uuid insert-data.jsに SDK を使って DynamoDB に登録する処理を書きます。 insert-data.js const { DynamoDBClient, PutItemCommand } = require("@aws-sdk/client-dynamodb"); const { v4: uuidv4 } = require('uuid'); (async () => { const client = new DynamoDBClient({ region: "ap-northeast-1", endpoint: "http://localhost:8000" }); const command = new PutItemCommand({ TableName: 'animals', Item: { "id": {"S": uuidv4()}, "Name": {"S": "pug"}, "AnimalType": {"S": "Dog"} } }); try { const results = await client.send(command); console.log('result:', results); } catch (err) { console.error(err); } })(); スクリプトを実行します。 $ node insert-data.js result: { '$metadata': { httpStatusCode: 200, requestId: 'c910a473-f2a4-41b2-8aab-5cdb6021d0ef', extendedRequestId: undefined, cfId: undefined, attempts: 1, totalRetryDelay: 0 }, Attributes: undefined, ConsumedCapacity: undefined, ItemCollectionMetrics: undefined } データが登録できたか、scan コマンドを実行して確認します。 $ aws dynamodb scan --endpoint-url http://localhost:8000 --table-name animals { "Items": [ { "AnimalType": { "S": "Dog" }, "id": { "S": "350d582d-b9cf-4c3f-9f5e-ef78b5493be6" }, "Name": { "S": "pug" } } ], "Count": 1, "ScannedCount": 1, "ConsumedCapacity": null } データが登録できているのが確認できました。お金をかけずに DynamoDB を使った開発ができそうですね。

Shell Executorを指定したにも関わらず、なぜかパイプライン実行時にDockerイメージが利用されることがあります。 対処法 GitLab Runnerでは、Specific Runnerを利用するには、.gitlab-ci.ymlにおいて、そのRunnerを明示する必要があります。そのため、GitLab Runnerセットアップ時にタグをつけておいて、.gitlab-ci.ymlでタグを指定する必要があります register時に初めからタグをつけておく ですので、GitLab Runnerを初期化するときには初めから以下のようにすべきです。 sudo gitlab-runner register の後にtokenなどを対話的に入力し、適当にlocal-runnerでもなんでもいいのでタグをつけてください。 あとはGitLabのCI/CD Editorにて以下のようにタグを明示するだけ。 .gitlab-ci.yml some-kinda-job: tags: - local-runner Tips: タグを最速でリセットするにはunregisterするしかない タグをregister後から変更する方法はググっても簡単に見つかりませんでした。 ですので、以下のようにRunnerを消して、後で再度セットアップしましょう。 sudo gitlab-runner unregister --url='XXX' --token='YYY' なお、url, tokenはGitLabのSetting->Runnerのところから再度確認してください 参考文献 公式ドキュメントが最強です

はじめに 最近の開発現場ではもはや当たり前のものとして整備されつつある、 CI/CDパイプライン ですが、私が参画した開発現場では導入されていませんでした。 CI/CDパイプラインは導入すると様々なメリットがあるので、導入した方が良いと思い、自ら社内の開発現場への導入を進めました。 CI/CDとは 簡単に説明するとアプリケーションのビルド、テスト、デプロイを自動で行い、開発の生産性を向上させるための開発の手法です。 CIのメリット Linterを実行することで規定されたルールに則っていないソースコードを事前に検知できる。 Formatterを実行することで、同一のリポジトリ内においてソースコードのフォーマットを強制的に統一することができる。 デバッグコードを事前に検知し、本番環境に不要なデバッグコードがリリースされることを未然に防ぐことができる。 アプリケーションのビルドが問題なく行われるかどうかのチェックを、本番環境へのリリース前に自動で行うことができる。 補足として、最後にあげたメリットに関しては本番環境をコンテナ基盤で運用している場合に教授できるメリットですがCIのメリットとして挙げられる代表的なものの一つとなるかなと思います。 リポジトリ内に本番環境用の Dockerfile を含めておいて、CIの処理の中に自動でビルドされるようにしておけば、もしビルドが失敗した際に事前に検知できるのかなと思います。 CDのメリット 本番環境へのリリース作業において社内の特定の人物しか把握していないというような状況を防ぐことができる。 リリース作業を自動化することで開発者の作業ミスを防ぐことができる。 アプリケーションのダウンタイムをゼロにすることができる。 CI/CD導入におけるデメリット 既存の開発現場にCI/CDの仕組みが整備されていない場合、チームの開発者にCI/CDの導入を前提とする開発スタイルに馴染ませる必要がある。 CI/CDパイプラインをメンテナンスする開発者が必要になる。 CI/CDの仕組みに関して、チームの開発者にキャッチアップを促す必要がある。 使用したCIツールとCIを実行する環境 使用しているCIツールは、gitlabでCIを行う際のデファクトスタンダードとなっている、 Gitlab Runner を使用しています。 クラウド上にCI専用のサーバー(CentOS7)を構築して、サーバー上に Gitlab Runner をインストールしてCI環境を整備しています。 ※CentOS7に Gitlab Runnerインストールする参考資料 こちらの記事に、gitlab上でCIを行う際の設定について解説されているので参考にしてください。 実際に使用しているCIスクリプト こちらのリポジトリにもまとめていますので、参考にしてください。 .gitlab-ci.yml image: php:7.4-fpm cache: key: one-key-to-rule-them-all paths: - vendor/ - node_modules/ before_script: - apt-get update - apt-get install -y git libzip-dev libpng-dev - docker-php-ext-install zip - curl --silent --show-error https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer - mkdir ~/.ssh - chmod 700 ~/.ssh - echo "$KNOWN_HOSTS" >> ~/.ssh/known_hosts - echo "$SSH_KEY" >> ~/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - eval "$(ssh-agent)" - ssh-add ~/.ssh/id_rsa - ssh-add -l - echo "$SSH_CONFIG" >> ~/.ssh/config - git remote set-url --push origin ssh://git@255.255.255.255:65535/web/sample_project.git - git remote -v - git remote update - git config --global user.name gitlab_runner - git config --global user.email gitlab.runner@example.com - if [[ `git branch | grep $CI_COMMIT_REF_NAME` ]]; then - git branch -D $CI_COMMIT_REF_NAME - fi - if [[ ! `git branch | grep $CI_COMMIT_REF_NAME` ]]; then - git branch $CI_COMMIT_REF_NAME origin/$CI_COMMIT_REF_NAME - fi - git branch stages: - build - formatter formatter: stage: formatter script: - git checkout $CI_COMMIT_REF_NAME - apt-get install -y lsof nodejs npm - npm install - pecl install mongodb - docker-php-ext-enable mongodb - git checkout $CI_COMMIT_REF_NAME - ssh -t -t web_app_db -f -N - lsof -i - composer install - cp .env.example .env - echo "$ENV_FILE" >> .env - php artisan key:generate - vendor/bin/phpunit tests/Feature/api_test.php - vendor/bin/phpunit tests/Feature/Api - SYNTAX_CHECK=0 - for FILE in `git diff --name-only origin/master | grep -E '*php'` ; do - echo $FILE - ./vendor/bin/php-cs-fixer fix $FILE - echo 'PHPMDで未使用変数などのチェック' - if ! ./vendor/bin/phpmd $FILE text ruleset.xml; then - SYNTAX_CHECK=1 - fi - done - IS_ERROR=0 - for FILE in `git diff --name-only origin/master | grep -E '*js'` ; do - if [ $FILE = '.eslintrc.json' ]; then - echo $FILE - echo "skip check" - continue - fi - if [ $FILE = 'composer.json' ]; then - echo $FILE - echo "skip check" - continue - fi - if [ $FILE = 'package-lock.json' ]; then - echo $FILE - echo "skip check" - continue - fi - if [ $FILE = 'package.json' ]; then - echo $FILE - echo "skip check" - continue - fi - if [ $FILE = WebGL_Release.framework.js ]; then - echo $FILE - echo "skip check" - continue - fi - if [[ -n `./node_modules/.bin/eslint --fix $FILE` ]]; then - ./node_modules/.bin/eslint --fix $FILE - IS_ERROR=1 - fi - done - git add -A - git status - if [[ -n "`git status --porcelain`" ]];then - git commit -m '[ci skip]Push by GitLab runner' - git push origin $CI_COMMIT_REF_NAME - fi - IS_ERROR_LOG_REMAIN_ERROR=0 - for FILE in `git diff --name-only origin/master | grep -E '*php'`; do - echo $FILE - if [[ -n `git grep error_log -- $FILE` ]]; then - echo -e "\e[31;43m デバッグコードが残っている可能性があります。'\n'削除してください \e[m" - IS_ERROR_LOG_REMAIN_ERROR=1 - else - IS_ERROR_LOG_REMAIN_ERROR=0 - fi - done - if [ $SYNTAX_CHECK -eq 0 -a $IS_ERROR_LOG_REMAIN_ERROR -eq 0 ]; then - exit 0 - else - echo -e "\e[31;43m 修正を行った上で再度コミットしてください \e[m" - exit 1 - fi except: - master CI運用時に発生した事象 今まで問題なく動いていたCIが、ある時を境に全プロジェクトで一斉にこけるという事態が発生しました。 その際に発生した問題と、実際に解決を図ったプロセスについて解決したいと思います。 発生した問題 CIの処理実行時に、以下の処理の部分でCIがこけてしまっていますね。 $ docker-php-ext-install zip Configuring for: PHP Api Version: 20190902 Zend Module Api No: 20190902 Zend Extension Api No: 320190902 ls: cannot access '.': Operation not permitted configure: error: working directory cannot be determined Cleaning up file based variables ERROR: Job failed: exit code 1 解決手順 1. ls: cannot access '.': Operation not permitted gitlab でgoogle検索 見出しのキーワードで検索すると、こんな記事が出てきました。 https://webclass.jp/blog/2021/07/01/docker%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E5%86%85%E3%81%A7-make-bin-sh-operation-not-permitted/ 何か、dockerのversionが関係している可能性があるようです。 2. CIサーバー上のDockerのversionを確認する。 サーバーにインストールされているdockerのバージョンを確認してみましょう。 サーバーにインストールされているdockerのversion [root@gitlab-runner ~]# docker -v Docker version 20.10.3, build 48d30b5 なるほど。 サーバーにインストールされているバージョンがわかったところで現在のdocker最新版を確認します。 ※docker最新バージョンを確認 https://openstandia.jp/oss_info/docker/version/ 3. インストール済みのdockerをremove 既存のdockerを一旦アンインストールします。 yum remove docker-ce docker-selinux docker-engine-selinux 4. docker最新版をインストール sudo yum install docker-ce -y 4. docker再起動 systemctl start docker ※dockerを最新版にするための参考資料 https://qiita.com/okcoder/items/e91f1e339c114e0be129 以上を行った後に、再度CIを走らせると処理が止まらずに無事にCIを実行することができました。 最後に gitlabでCIを行うとすると自前でサーバーを用意して、運用も自分たちで行う必要があるため、少し大変な面もありますが、安定して運用が行えるように環境を整備していきたいと思います。

目的 以下の内容の Docker イメージを作成する C++ コンパイラのインストール atcoder-cli + online-judge-tools のインストール GitHub から Atcoder 作業用リポジトリのクローン 環境 OS: Ubuntu 20.04 (WSL2) Docker version 20.10.6 成果物 Docker イメージ詳細 事前準備 GitHub に Atcoder 作業用リポジトリを準備する ssh キーを作成し、秘密鍵を ssh ディレクトリに保存、公開鍵を GitHub にアップロードする Atcoder 用テンプレートファイルを修正する main.cpp(デフォルト) #include<bits/stdc++.h> using namespace std; int main() { return 0; } Dockerfile イメージ元の指定 Dockerfile FROM centos:centos8 今回は centos8 から作成 環境変数の定義 Dockerfile ARG username ARG reponame github のユーザー名・リポジトリ名を変数として定義 必要なパッケージのインストール Dockerfile RUN yum update -y && yum install -y git gcc-c++ python3 nodejs git GitHub 連携 gcc-c++ C++ コンパイラ (gcc 8.4.1) python3 pip3 のインストール nodejs npm のインストール atcoder-cli のインストール Dockerfile RUN npm update -g npm && npm install -g atcoder-cli online-judge-tools のインストール Dockerfile RUN pip3 install online-judge-tools atcoder-cli の設定 Dockerfile RUN acc config oj-path /usr/local/bin/oj \ && acc config default-test-dirname-format test \ && acc config default-template cpp \ && acc config default-task-choice all acc config oj-path /usr/local/bin/oj atcoder-cli と online-judge-tools の連携 acc config default-test-dirname-format test サンプルテストファイルの保存先ディレクトリを online-judge-tools に合わせる acc config default-template cpp テンプレートファイルの保存先ディレクトリを指定 acc config default-task-choice all コンテスト用ディレクトリを一度にすべて作成するように設定 テンプレートファイルのコピー Dockerfile COPY cpp /root/.config/atcoder-cli-nodejs/cpp ローカルに用意したテンプレートファイルを Docker イメージにコピーする ssh 設定 Dockerfile COPY ssh /root/.ssh ローカルに用意した ssh 設定を Docker イメージにコピーする Atcoder 作業用リポジトリのクローン Dockerfile WORKDIR /work RUN chmod 600 /root/.ssh/* \ && git clone git@github.com:${username}/${reponame}.git 作業ディレクトリ/workを作成 chmod 600 /root/.ssh/* 秘密鍵の権限を変更 git clone git@github.com:${username}/${reponame}.git Atcoder 作業用リポジトリのクローン 以上をまとめる Dockerfile FROM centos:centos8 ARG username ARG reponame RUN yum update -y && yum install -y \ git \ gcc-c++ \ python3 \ nodejs \ && npm update -g npm && npm install -g atcoder-cli \ && pip3 install online-judge-tools \ && acc config oj-path /usr/local/bin/oj \ && acc config default-test-dirname-format test \ && acc config default-template cpp \ && acc config default-task-choice all COPY cpp /root/.config/atcoder-cli-nodejs/cpp COPY ssh /root/.ssh WORKDIR /work RUN chmod 600 /root/.ssh/* \ && git clone git@github.com:${username}/${reponame}.git docker-compose.yml バージョンの指定 docker-compose.yml version: "3" 最新バージョン ビルド docker-compose.yml build: context: . args: username: ktsn-ht reponame: atcoder context: . Dockerfile のあるディレクトリ args: ~ Atcoder 作業用リポジトリのユーザー名・リポジトリ名を指定 自分の場合: https://github.com/ktsn-ht/atcoder イメージ名の指定 docker-compose.yml image: atcoder-cli コンテナ名の指定 docker-compose.yml container_name: atcoder-cli コンテナを起動し続ける docker-compose.yml tty: true 以上をまとめる docker-compose.yml version: "3" services: app: build: context: . args: username: ktsn-ht reponame: atcoder image: atcoder-cli container_name: atcoder-cli tty: true コンテナの起動・作業・終了 コンテナ起動 $ docker-compose up -d --build # イメージビルド・コンテナ起動 $ docker-compose exec atcoder-cli /bin/bash # コンテナに入る コンテナ内作業 # acc login # atcoder-cli でログイン # oj login https://beta.atcoder.jp/ # online-judge-tools でログイン # acc new <contest id> # コンテストディレクトリ作成 # oj t # 作成したプログラムのテスト # acc submit # 提出 # git push # GitHub に push コンテナ終了 # exit # コンテナから出る $ docker-compose down # コンテナ終了・削除 おわりに Docker の勉強のために Atcoder 環境のイメージを作成してみました。間違いやもっと良いやり方などある場合はご指摘いただければ幸いです。 せっかくつくったので久しぶりにコンテストも参加しようかな。。 参考 atcoder-cli チュートリアル | わたしろぐ Dockerfile リファレンス — Docker-docs-ja 20.10 ドキュメント Compose file version 3 reference DockerでAtCoderができる環境を作る【Python・C++】 - Qiita AtCoder のディレクトリ作成・サンプルケースのテスト・提出を自動化する。atcoder-cli と online-judge-tools - Qiita atcoder初心者こそ環境構築しよう！(atcoder-cli,online-judge-toolsのインストール、使い方） - Qiita Dockerで作るGitHub環境 - Qiita docker-compose up したコンテナを起動させ続ける方法 - Qiita

aws cli の docker イメージが公式から提供されていました。 awsコマンドで aws cli の docker コンテナを簡単に起動できるように設定してみます。 設定してみる awsコマンドで docker コンテナが立ち上がるように、 alias を設定します。 alias aws='docker run --rm -it -v ~/.aws:/root/.aws amazon/aws-cli' alias が設定できているか確認します。 $ aws --version aws-cli/2.2.37 Python/3.8.8 Linux/4.19.128-microsoft-standard docker/x86_64.amzn.2 prompt/off ~/.awsに認証情報がない場合は、configureコマンドで作成します。 $ aws configure AWS Access Key ID [None]: dummy AWS Secret Access Key [None]: dummy Default region name [None]: ap-northeast-1 Default output format [None]: json ホスト側に認証情報が作成されているか確認します。 $ cat ~/.aws/credentials [default] aws_access_key_id = dummy aws_secret_access_key = dummy おわりに docker コンテナで aws cli の設定できるのは便利ですね。aws cli のバージョンが今後上がったとしても、docker image のバージョンを変えるだけで任意のバージョンに簡単に変更できるので、使い道は多そうです。

はじめに 以下のような構成で記事を執筆していますが、 どこからでも読めるような構成になっています。 ゼロから始めるDocker入門 はじめてのDockerfile はじめてのDocker compose ←今回はここ 対象読者 Docker の使用に慣れてきた方 docker-compose.yml でなにをしているのか知りたい方 目次 はじめに 対象読者 目次 Docker Composeとは Docker compose ディレクトリ構造 docker-compose.yml Dockerfile Compose コマンド おわりに 参考文献 Docker Composeとは docker-compose.yml という yml 形式のファイルに 複数のコンテナを定義し実行することができるツールです。 Docker compose どのように書いていくのか確認していきます。 (※ 最低限の設計です) ディレクトリ構造 . ├── docker │ └── Dockerfile └── docker-compose.yml docker-compose.yml docker-compose.yml # バージョンの指定 version: '3.9' # サービス定義 services: app: # サービス名(コンテナ名) build: # build context: . # build context dockerfile: docker/Dockerfile # Dockerfile の指定 ports: # port指定(ホストのポートをコンテナのポートにつなげる) # host:container - "8000:80" volumes: # マウント(ファイルシステムの共有) # host:container - '.:/var/www/html' Dockerfile docker/Dockerfile # php のイメージ FROM php:7.4-fpm # コマンド実行ディレクトリ WORKDIR /var/www/html # パッケージインストール RUN apt-get update \ && apt-get install -y libonig-dev libzip-dev unzip Compose コマンド 使用頻度の高いコマンドです。 　コマンド 意味 docker-compose build コンテナをbuildする docker-compose up -d デタッチドモードで立ち上げ docker-compose stop 実行中のコンテナを停止 docker-compose down 実行中のコンテナを停止し削除 docker-compose restart コンテナを再起動 docker-compose exec [サービス名（コンテナ名）]　[command（bash）] コンテナに対しコマンド実行。bashを書くとコンテナ内に入ることができる。 おわりに 今回3部構成で記事を執筆いたしました。 すべて読みすすめたら Docker に対して困ることは少なくなるのかなと思います。 もちろんすべてを網羅したわけではないですし、説明不足な点もあるかもしれませんが、 「Dockerって何？」 というところから抜け出すきっかけになりましたら幸いです。 記事で足りない点は調べて補いつつ、さらに理解を深めたいときは 教材など購入、公式ドキュメントなど読みながら手を動かしてみると深く学ぶことができるのではないでしょうか。 参考文献 Docker Compose docker と docker-compose の初歩 Docker compose ことはじめハンズオン マウント (mount)

BuildKit を有効にして docker build した場合、どのくらい高速になるのか確認しました。 BuildKit 詳細まで理解していませんが、ざっくりまとめると、 依存関係のない命令を並列実行できる コンパイラやパッケージマネージャのキャッシュディレクトリを保持できる これらの仕組みにより、ビルドを高速化しているようです。 利用方法 BuildKit は docker v18.06 から使えます。 環境変数 DOCKER_BUILDKIT=1 を設定するだけで有効になります。 BuildKit 無効のとき BuildKit を無効化。 $ export DOCKER_BUILDKIT=0 中間レイヤ削除とキャッシュ不使用のオプションを付けてビルド。 $ docker build . --rm --no-cache -t rails_app -f dockerfiles/rails/Dockerfile ビルド時間は 4m27s でした。 BuildKit 有効のとき 次は有効にしてビルドしてみます。 $ export DOCKER_BUILDKIT=1 $ docker build . --rm --no-cache -t rails_app -f dockerfiles/rails/Dockerfile ビルド時間は 2m54s でした。 約35%のビルド時間削減になりました！（もちろん環境やイメージの内容にも依りますが） ビルド時間の短縮以外で嬉しかったこと ビルド中の画面出力が見やすくなっていました。 従来のビルドでは膨大な長さになる上に内容も分かりにくかったです。 BuildKit では、ステータスがレイヤ毎にまとめられています。 また、並列に処理が進んでいることが見て分かるようになってます。 まとめ BuildKit を有効にしてビルド時間が短縮できることが確認できました。 BuildKit にはこの他にも機密情報をコンテナに渡すためのオプションや、SSH エージェントによる接続を許可するオプションなどが追加されているようです。またの機会に試してみたいと思います。 ちなみに、ビルドした Dockerfile はこちらです。

Ansible という自動化ツールを使って AWS EC2 t3.nano インスタンス上にボタンひとつで Redmine を作ります。一旦作るとパラメータを変えて何度もデプロイしたり、複数の Redmine を簡単にデプロイできるというのが味噌です。t3.nano というのはラズパイ程度のパワーがあるそうです。当初 AWS CloudFormation だけでやろうとしたのですが、謎のおまじないが多く嫌になったので Ansible を併用する事にしました。 ここで出来た Redmine はデプロイし直すとデータが消えるので実用性はありませんが、話が長くなるので最低限の部分だけ書きます。 前準備 以下の準備ができている事前提です。 AWS CLI: aws configure が終わっている。 Ansible: 私は brew install ansible でインストールしました。 Docker: 出来るだけ使わないで済まそうかと思いましたが楽さに負けました。確認のため手元にインストールしておきます。 SSH key pair の作成 これから作る EC2 にアクセスする鍵の作成です。ここだけ手動です。 aws ec2 create-key-pair --key-name hogekey --query 'KeyMaterial' --output text > hogekey.pem chmod 400 hogekey.pem EC2 の準備 まず CloudFormation の設定ファイルを cfn_redmine.yml という名前で作ります。 AWSTemplateFormatVersion: "2010-09-09" Resources: WebServer: Type: AWS::EC2::Instance Properties: InstanceType: t3.nano # ラズパイ程度のインスタンス ImageId: ami-02892a4ea9bfa2192 # Amazon Linux 2 64-bit x86 KeyName: hogekey # 先程作った鍵の名前 SecurityGroups: - Ref: WebServerSecurityGroup WebServerSecurityGroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: Redmine security SecurityGroupIngress: - CidrIp: 0.0.0.0/0 # 全世界から見える設定 FromPort: '3000' # Redmine のために開けるポート IpProtocol: tcp ToPort: '3000' - CidrIp: xxx.xxx.xxx/32 # ご自宅の IP。自宅からしか見えないように。 FromPort: '22' # SSH のために開けるポート IpProtocol: tcp ToPort: '22' Outputs: PublicIP: Value: !GetAtt WebServer.PublicIp WebsiteURL: Value: !Sub "http://${WebServer.PublicDnsName}:3000" まずはこれだけで動くか確認します。 # まず実行 $ aws cloudformation create-stack --stack-name redmine --template-body file://cfn_redmine.yml # しばらく待って出来上がった IP を確認 $ aws cloudformation describe-stacks --stack-name redmine | grep OutputValue "OutputValue": "52.196.137.57", "OutputValue": "http://ec2-52-196-137-57.ap-northeast-1.compute.amazonaws.com:3000", # 返ってきた IP の ec2-user ユーザにログインする。 $ ssh -i hogekey.pem ec2-user@52.196.137.57 Redmine を手元で動かす 色々試しましたが結局 redmine を一番簡単に動かすには docker が楽だと分かったので、次のような docker-compose.yml ファイルを作成します。 version: '3.1' services: redmine: image: redmine restart: always ports: - 3000:3000 environment: REDMINE_DB_MYSQL: db REDMINE_DB_PASSWORD: example REDMINE_SECRET_KEY_BASE: supersecretkey REDMINE_DB_ENCODING: utf8mb4 db: image: mysql:5.7 restart: always command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: example MYSQL_DATABASE: redmine 念の為手元でちゃんと動くか確認します。docker stack というやつの方が堅牢らしいですが、ログを見るのが面倒なので　docker-compose を使いました。 起動 docker-compose up http://localhost:3000/ にアクセスして Redmine が動いているか確認。admin/admin でログイン出来ます。 Ctrl + C で起動した docker-compose を止めてから削除 docker-compose down Redmine をリモートで動かす 確認した docker-compose.yml を Ansible で EC2 上で動かします。Ansible の操作対象を指定するには、hosts という名前のファイル((inventory と呼びます) を作り、先程 describe-stacks で取得した IP と EC2 のユーザ名を以下のように書き込みます。これで Ansible から aws というグループ名で操作出来ます。 [aws] 52.196.137.57 ansible_user=ec2-user EC2 の初期設定を済ませ docker-compose を実行する Ansible の設定ファイル (playbook と呼びます) です。configure.yml という名前で作ります。ここの味噌は t3.nano のメモリが無さすぎるのでスワップメモリを用意する部分です。 - name: root で実行する設定 hosts: aws # 操作対象の EC2 インスタンスのグループ名 become: yes # root で実行する。 tasks: - name: yum の更新 command: yum update -y - name: Docker インストール yum: name: docker - name: ec2-user を docker グループに追加 user: name: ec2-user append: yes groups: docker - name: グループ追加が反映されるように一旦接続を切る meta: reset_connection - name: Systemd による Docker 自動起動 systemd: name: docker enabled: yes state: started - name: docker-compose インストール shell: | curl -L https://github.com/docker/compose/releases/download/1.29.2/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose - name: Swap メモリが設定済か調べる stat: path=/swapfile register: swapfile - name: Swap が未設定なら t3.nano ではメモリが足りないので 512M の Swap を作る when: swapfile.stat.exists == False shell: | dd if=/dev/zero of=/swapfile bs=128M count=4 chmod 600 /swapfile mkswap /swapfile swapon /swapfile swapon -s echo "/swapfile swap swap defaults 0 0" >> /etc/fstab - name: ec2-user で実行する設定 hosts: aws # 操作対象の EC2 インスタンスのグループ名 tasks: - name: docker-compose.yml をアップロード copy: src: docker-compose.yml dest: /home/ec2-user owner: ec2-user group: ec2-user mode: "0644" - name: docker-compose 起動 command: docker-compose up -d ここまで実行してみます。 ansible-playbook -i hosts configure.yml --private-key hogekey.pem 全部一発で動かす。 いよいよ本題です。ここまでは AWS の設定に CloudFormation、サービスのインストールと起動に Ansible Playbook という適材適所で自動化を進めました。これをコマンド一つで繋げられないでしょうか? これを実現するには、Ansible はCloudFormation で作成した EC2 の IP アドレスを知る必要があります。 上記の方法では　Ansible の接続先を hosts ファイルに設定しました。このままでは EC2 を作る度に手動で hosts ファイルを書き換えないといけません。そこで、CloudFormation を Ansible 経由で起動して IP アドレスを取得する事にします。 今から provision.yml という名前でファイルを作ります。まず、この playbook はローカルで動くので hosts: localhost と指定します。 - name: AWS を構築する hosts: localhost gather_facts: false connection: local Ansible には cloudformation を実行するモジュールが用意されているので、cloudformation を呼ぶ事自体は簡単です。 tasks: - name: CloudFormation 作成 cloudformation: stack_name: redmine disable_rollback: true template: cfn_redmine.yml 出来上がった EC2 の情報を収集するには ec2_instance_info を使います。集めた情報は ec2_list という変数に入ります。ここで、redmine スタックで作った EC2 だけをフィルタするために "tag:aws:cloudformation:stack-name": redmine を使っています。これは CloudFormation が自動でつけてくれる tag です。DB など二種類以上の EC2 を作る場合は自分で tag をつけて見分ける必要があります。 - name: EC2 情報取得 ec2_instance_info: filters: instance-state-name: [ "running" ] "tag:aws:cloudformation:stack-name": redmine register: ec2_list 作った EC2 を捜査対象 (inventory) に加えるには add_host を使います。ここで先程集めた ec2_list はリストなので loop 構文で要素を取り出します。集めたホスト名をユーザ名(ec2-user 固定) とともに aws グループに追加します。これは上記 hosts ファイルで言うと [aws] 以下に記入するのと同じです。 - name: EC2 を inventory に入れる add_host: name: "{{ item.public_dns_name }}" ansible_user: ec2-user host_key_checking: false groups: aws when: ec2_list.instances|length > 0 loop: "{{ ec2_list['instances'] | flatten(levels=1) }}" 早速作った aws グループにアクセスします。EC2 が起動して SSH 接続が有効になるまでしばらく待ちます。 - name: EC2 の完成待ち hosts: aws gather_facts: false vars: ansible_ssh_common_args: "-o StrictHostKeyChecking=no" tasks: - name: wait for instances to become available wait_for_connection: 最後に先程作った configure.yml を実行します。 - import_playbook: configure.yml 実行方法。実行対象は localhost と動的に集めた EC2 なので -i で inventory を指定する必要はありません。 ansible-playbook provision.yml --private-key hogekey.pem 一旦 aws cloudformation delete-stack --stack-name redmine で削除してから上を実行すると、本当にボタン一発で redmine が出来上がるのを確認出来ます。 参考 https://muhannad0.github.io/post/cloudformation-and-ansible-provision-and-configure/ ほぼここに書いてある事をパクリました。 Ansible Working With Playbooks: https://docs.ansible.com/ansible/2.9/user_guide/playbooks.html この旧版のドキュメントの方がわかりやすいと感じました。日本語もありますが表示が崩れているので併用すると良いです。 https://hub.docker.com/_/redmine Redmine の Docker オフィシャル https://knooto.info/docker-redmine4-setup/ 寿司ビール問題の参考にしました。 https://stackoverflow.com/questions/26677064/create-and-use-group-without-restart ec2-user を docker group に追加しても即反映されず焦りました。

shellで、あるリストを単語ごとに分割しようとした矢先、mecabというライブラリを発見。 そのライブラリ及び専用の辞書ツールを試しにGoogle Colabで利用して便利であったため、Linux環境にも導入したい。 そこで今回はDockerのUbuntu20.04内に導入する方法を記録する。 環境 Mac OS 11.2.3 Docker version 20.10.8 手順 任意のディレクトリに以下でDockerfileを作成する。 # workディレクトリ内にmecab-conディレクトリを作成 mkdir ~/work/mecab-con; cd $_ # mecab-con内にDockerfileを作成 touch Dockerfile 作成後、mecab-con/Dockerfileの中身を以下にする。 ~/work/mecab-con/Dockerfile FROM ubuntu:20.04 # 日本設定 ENV TZ Asia/Tokyo RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone ENV LANG ja_JP.UTF-8 # パッケージインストール RUN apt update -yqq && \ apt install -y --no-install-recommends \ build-essential curl ca-certificates \ file git locales sudo \ mecab libmecab-dev mecab-ipadic-utf8 && \ locale-gen ja_JP.UTF-8 && \ apt clean && \ rm -rf /var/lib/apt/lists/* # mecab-ipadic-neologdインストール WORKDIR /tmp RUN git clone --depth 1 https://github.com/neologd/mecab-ipadic-neologd.git && \ ./mecab-ipadic-neologd/bin/install-mecab-ipadic-neologd -n -y && \ sudo mv /usr/lib/x86_64-linux-gnu/mecab/dic/mecab-ipadic-neologd /var/lib/mecab/dic/ && \ sed -i 's/debian/mecab-ipadic-neologd/' /etc/mecabrc && \ rm -rf ./mecab-ipadic-neologd && \ echo "完了" 内容を記述後、以下のコマンドでコンテナの立ち上げ及び起動を行う。 # ビルド docker build -t mecab-con . # 起動及び接続 docker run -it mecab-con コンテナの中へ接続後、以下でmecabが利用できることを確認できたら完了。 # バージョン確認 mecab -v # 解析 echo "せっかちなかたつむり" | mecab せっかち 名詞,形容動詞語幹,*,*,*,*,せっかち,セッカチ,セッカチ な 助動詞,*,*,*,特殊・ダ,体言接続,だ,ナ,ナ かたつむり 名詞,一般,*,*,*,*,かたつむり,カタツムリ,カタツムリ # 辞書指定 echo "白石麻衣" | mecab -d /var/lib/mecab/dic/ipadic-utf8 白石 名詞,固有名詞,人名,姓,*,*,白石,シライシ,シライシ 麻衣 名詞,固有名詞,人名,名,*,*,麻衣,マイ,マイ # 読み echo "薔薇" | mecab -O yomi バラ # 分かち書き echo "せっかちなかたつむり" | mecab -O wakati せっかち な かたつむり # 指定のtsvから解析して名詞のみを抜き出す。 cut -f1 ＊＊.tsv | mecab | grep '名詞' | cut -f1 まとめ Linux環境への導入したことで標準出力や任意のデータの解析や分解が容易になった。 様々な利用の仕方があると思われるため、用途によって積極的に活用していく。 参考 https://taku910.github.io/mecab/ https://github.com/neologd/mecab-ipadic-neologd https://www.kkaneko.jp/tools/ubuntu/ubuntu_mecab.html

以前まではwindows 10 ProでないとDocker使えませんでしたが、Windows 10 Home でもDockerが簡単に使えるようになっています。MacとかWindows 10 Proの導入はたくさんあるけど、長年Homeで使えなかったので今回記事にします。 Django(Python)の記事をよく書いていますのでwindows homeで環境を構築しようと思います すでにDocker使ってて、Docker + Django + PostgreSQLの環境構築したい人はDockerでDjangoを動かすから見れば構築できると思います。 環境 Windows 10 Home 21H1 Docker Desktop for Windows 4.0.0 まあ、最近のwindowsのアップデートちゃんとやってれば使えると思います Dockerで構築するDjango環境 ローカルで開発するときに使えるDjango構築していきます。 Django 3.2 PostgreSQL こちらは、慣れてきたら変更可能なので適時変更してください。 ついでに、Django関係で初心者向け記事も書いてますのでよろしければ。 【Python Django】初心者プログラマーのWebアプリ 【丁寧解説】秒速でもDjango 3アプリをAWS EC2で公開【Nginx, gunicorn, postgresqlデプロイ】 ソースコード この章の完成時コードは以下です。確認やコピペでどうぞ ダウンロードとインストール Docker Desktop Installer.exeをダウンロードしてください。 実行する。 結構時間かかるかも。ポチポチ進めていけばOK Close and restartとかCloseとか出るので押してください。 これでOKかと思ったらWSL2のインストール必要みたいです。 まあ面倒なのがここだけですので頑張りましょう。 ダウンロード先 x64 マシン用 WSL2 Linux カーネル更新プログラム パッケージ みたいなリンクあるのでダウンロードしてください。 ダウンロードできたら実行。 Next押して行ってFinish押せば完了しました。 再起動したらインストール作業は完了です。 Dockerを起動して右下のクジラが白いのが正常です。 windows 10 homeでDocker使いたいだけの人ならこれで終了です。 DockerでDjangoを動かす これ以降はDjango環境をローカルに構築します。 最初に起動したらDockerのチュートリアルも表示されたと思いますが、今回はDjangoの環境を構築してみましょう。 フォルダ作ってDockerfileを作成 好きなところにフォルダ作ってその中にDockerfileを作成します。 Dockerfileがよくわからない方は環境の作る手順書かれたファイルみたいに思っておけばいいかと。 # syntax=docker/dockerfile:1 FROM python:3 ENV PYTHONUNBUFFERED=1 WORKDIR /app COPY requirements.txt /app/ RUN pip install -r requirements.txt COPY . /app/ 細かく内容説明 使いたいだけなら次にいってOK FROM python:3: Python 3 の最新イメージを使用 ENV PYTHONUNBUFFERED=1: 「ENV」は環境変数の設定。Python使うときの環境変数 WORKDIR /app: これ以降どこのディレクトリで作業するか COPY requirements.txt /app/: ファイルコピーrequirements.txtを作りましたよね。- - /appにディレクトリにコピーしてる。仮想環境なのでコンテナの中には今のところファイル存在ないのでコピー必要 RUN pip install -r requirements.txt: RUNがコマンド実行ということ。pip installして必要パッケージをテキストで記述してまとめてインストールするために使う COPY . /app/: この時点でrequirements.txtしかファイル存在してない。これではアプリ動きようがないのでDjangoアプリのファイル全部コピーしてる requirements.txt作成してインストールするパッケージを記述 先ほどDockerfileでも触れましたがDokcerの環境で使用するパッケージをまとめてインストールしてもらうためにrequirements.txtに記述します。 requirements.txt Django>=3.2,<3.3 psycopg2-binary>=2.8 インストールするDjangoとPostgreSQLをDjango使うために必要なパッケージを記述します。 メジャーバージョンだけ上がらないようにしており、かなりバージョンが雑に指定しているので、Django>=3.2,<3.3とか絞ったほうが本来はいいと思います。 docker-compose.yml作成 とりあえず動けばいいかくらいの設定です。 docker-compose.yml version: "3.9" services: db: image: postgres volumes: - ./data/db:/var/lib/postgresql/data environment: - POSTGRES_DB=postgres - POSTGRES_USER=postgres - POSTGRES_PASSWORD=postgres web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/app ports: - "8000:8000" depends_on: - db 細かく内容説明 使いたいだけなら次にいってOK version: Docker-composeのバージョン「3」とかでもいいです。 services: 今回使うのはPostgreSQL、Djangoアプリなのでそれぞれ「db」「web」という名前つけてます。 db: イメージは取得してきたpostgresを使用します。既製品という感じ？ volumes: コンテナってデータ保持能力ないんです。動いてるときはいいけど、毎回消えます。それだとDBの意味ないですよね。ということでローカルの./data/dbに保存したというか、共有したというか思っておけばとりあえずいいと思います。 environment: コンテナ内だけで使う環境変数設定できるので設定。 web: Djangoアプリ用。Linux環境にPython入ってる環境を改造して色々入れてる感じ。 build: . つまりdocker-composeにあるディレクトリでビルドしてる。dockerfileのディレクトリ注意 command:　コマンド実行してるサーバー立ち上げてる。ついでに起動した開発サーバー止まるとコンテナ止まる。 ports:　ポートフォワード。ホスト側8000番→コンテナ8000番に通してる。だからブラウザにlocalhost:8000で繋げることができてる。 environment: settings.pyで使う環境変数なので重要 depends_on: DB起動してからでないとDjango使えないというか、エラー出るので上で決めた「db」が起動してから「web」起動してねってこと Djangoのプロジェクト作成 コマンドラインにて以下を実行。今回はプロジェクト名はappで作ります。 docker-compose run web django-admin startproject app . docker-compose runが単体で起動。webと定義したもので、django-admin startproject app .を実行してください、ということ。 Django使ったことある人ならわかると思うけど、Djangoで最初にプロジェクト始めるためのコマンド。 初めて実行すると構築に必要なイメージを勝手に取得してくれますのでしばらくかかります。 => [2/5] WORKDIR /app 36.1s => [3/5] COPY requirements.txt /app/ 0.2s => [4/5] RUN pip install -r requirements.txt 10.4s => [5/5] COPY . /app/ 1.7s => exporting to image 1.2s => => exporting layers 1.2s => => writing image sha256:394255b3848438c6533f150499a35141a7c2a886a143aa4e34b4c57adb5z59ac 0.0s => => naming to docker.io/library/django_docker_web 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them こんな感じの表示出たらOK volumeにDBの記載したからDB関係のファイル大量にできるはず。pushするとかで気になる人は後で記述する.gitignoreで除外するようにしてください。 settings.pyにDBの設定を追加 DB起動できないので設定を変更。とりあえず、これでDBにつなげるからデータ保存などできる。 django_docker/app/settings.py ... DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': 'postgres', 'USER': 'postgres', 'PASSWORD': 'postgres', 'HOST': 'db', 'PORT': 5432, } } ... docker-compose up でDjango起動 では、起動コマンド。 docker-compose up これでエラーが出なければこんなふうに起動すると思います。 http://localhost:8000/ はい、ちゃんと起動しました！！ その他の設定 以降は必須でないです。すでにDocker + Docker + PostgreSQLは使えます。 チャレンジしてもいいと思います。 Djangoの設定いじる 日本時間の方が都合がいいと思うのでいじります。 django_docker/app/settings.py LANGUAGE_CODE = 'ja' TIME_ZONE = 'Asia/Tokyo' 日本語なりました。管理画面や、時間を扱うとき地味に重要です。 DBのデータをpushするのはよくない 現状だとDBのデータや設定が書いてある大量のファイルがpushされます。差分が大量にあるのも良くないし、見せてはいけないデータあったら大変なのでgithubにpushされないようにします。 .gitignoreを作って、/dataを追加してください。差分が激減します。 ついでに、Python関係で一般的にpushされるとやばいファイルについても追加したものがソースコードにありますので、必要な方はコピペしてください。 .gitignore data/ docker-composeで環境変数を設定 まあ、必要ないけどデプロイのとき環境変数の使い方知ってるとよいので設定しておきます。 django_docker/app/settings.py import os ... SECRET_KEY = os.environ.get('SECRET_KEY') ... DEBUG = bool(int(os.environ.get('DEBUG', 0))) ... DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql', 'NAME': os.environ.get('DB_NAME'), 'USER': os.environ.get('DB_USER'), 'PASSWORD': os.environ.get('DB_PASSWORD'), 'HOST': os.environ.get('DB_HOST'), 'PORT': int(os.environ.get('DB_PORT')), } } django_docker/docker-compose.yml services: db: image: postgres volumes: - ./data/db:/var/lib/postgresql/data environment: - DB_NAME=postgres - DB_USER=postgres - DB_PASSWORD=postgres - DB_HOST=db - DB_PORT=5432 - DEBUG=1 - SECRET_KEY=devsecretkey depends_on: - db ついでに、起動するときに--buildつけるとビルドして起動してくれるから便利。 docker-compose up --build 問題なく起動するか確認してくださいね。 VS Codeの拡張機能でWindows使いながらLinux使う 補足情報です。やりたい人だけで構いません。 Windowsだとコマンドプロンプト使わないといけなかったり、色々面倒なことあります。 Windows使ってるけど、Linux使いたいなーという人に役立つ機能。 VS codeの拡張機能追加でRemote Developmentと検索して追加。 左下の緑のボタン押してやると選択項目出るのでOpen Folder in Container 私の場合はdjango_dockerを指定。 From Dockerfile選ぶと今回構築に使用したPythonイメージ、つまりLinux開発環境がWindowsで手に入ります。 最初は少し時間かかるかも。 終わったら、こんな感じでちゃんとコマンド使えます。 ソースコード この章のコードは以下です。確認やコピペでどうぞ

概要 2020年10月からdocker hubのリポジトリからpullする時に未ログインした状態でpullすると任意のIP単位で制限をかけるような仕様を追加した。 これを解決するにはdocker loginをするしかない。 また、code buildはawsのマネージドサービスで動いているため、数回動かしただけでrate limitsエラーが表示されてしまう。 このエラーを回避するためにはcode buildのbyildspec.yamlでコンテナをビルドする前にdocker loginをする必要がある。 詳しくは以下。 buildspec.yamlの例 変数はcode build経由で渡すなりsecret manager経由で渡すなり、セキュリティ要件とやりやすさを考えてやってもらえますと。 version: 0.2 phases: install: commands: - echo install is nothing... - AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text) pre_build: commands: - echo Logging in to Amazon ECR... - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com - echo ${DOCKER_HUB_PASSWORD} | docker login -u ${DOCKER_HUB_ID} --password-stdin build: commands: - echo build docker image - docker build -t $CONTAINER_IMAGE . - docker tag $CONTAINER_IMAGE_REPO_NAME:$CONTAINER_IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$CONTAINER_IMAGE_REPO_NAME:$CONTAINER_IMAGE_TAG post_build: commands: - echo todo is nothing... - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$CONTAINER_IMAGE_REPO_NAME:$CONTAINER_IMAGE_TAG