Ansible Moleculeでテストを実行する時にテスト対象になるDockerイメージの作成方法について解説します。 今回はGitHub Actionsを用いてGitHubコンテナレジストリへDockerイメージを登録するまでになります。 なぜテスト環境用のDockerイメージを作成、登録するのか？ CIの実行時間を短縮するため コードの記述量を減らしメンテナンスしやすくする これらの理由が考えられます。 CIの実行時間を短くする Moleculeの機能から言えばMolecule実行時にDockerfileからテスト環境用のコンテナを作成する事は可能です。しかし毎回イメージをビルド、コンテナを起動しているとCIの実行時間が長くなってしまいます。 コードの記述量を減らしメンテナンスしやすくする テスト環境用のDockerfileを一箇所で管理する事によりメンテナンスコストが減らせます。例えばAnsible Role / Playbookでリポジトリがそれぞれ分かれていてなおかつそれぞれのリポジトリでDcokerfileが管理されている場合Dockerfileに変更が生じると全てのリポジトリに対して修正を行う必要が出てきます。これは相当悪手なので絶対に避けます。 ゴールデンイメージの仕様 ゴールデンイメージの設計図となるDockerfileには以下を含めます イメージのアップデート処理 Ansibleを実行するユーザーの作成 Ansible実行ユーザーへroot権限の付与 sshdはインストールしない？ Ansibleは標準でDockerコンテナへの実行をサポートしています。そのためsshdはインストールしません。 How to build your inventory — Ansible Documentation Dockerfileのサンプル例 Dockerfile FROM centos:8 # Install requirements RUN dnf clean all \ && dnf update -y \ && dnf install -y sudo # Create `ansible` user with sudo permissions ENV ANSIBLE_USER=ansible SUDO_GROUP=wheel RUN set -xe \ && groupadd -r ${ANSIBLE_USER} \ && useradd -m -g ${ANSIBLE_USER} ${ANSIBLE_USER} \ && usermod -aG ${SUDO_GROUP} ${ANSIBLE_USER} \ && sed -i "/^%${SUDO_GROUP}/s/ALL\$/NOPASSWD:ALL/g" /etc/sudoers GitHub Actoinsのサンプルファイル .github/workflows/build.yml --- name: build on: [deployment, push] jobs: github-container-registory: runs-on: ubuntu-latest strategy: matrix: base-image: [centos7, centos7jp, centos8] steps: - name: Checkout uses: actions/checkout@v2 - name: Set up QEMU uses: docker/setup-qemu-action@v1 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v1 - name: Login to GitHub container resigtory uses: docker/login-action@v1 with: registry: ghcr.io username: ${{ github.actor }} password: ${{ secrets.CR_PAT}} - name: Build and push uses: docker/build-push-action@v2 with: file: ${{ matrix.base-image }}/Dockerfile push: true tags: ghcr.io/org/repo/${{ matrix.base-image }}:latest 参考サイト コンテナレジストリの利用 - GitHub Docs 今回の記事のサンプルになるGitHubリポジトリ docker-hub-tm/ansible-test_centos at 225a8dab63650ce42cc11ec50fb4d8e43ebf43f4

はじめに こんにちは。DMM WEBCAMP Advent Calendar 2021　17日目を担当する@yuttana1223です！ 最近1年ぶりにLaravelを使用するということになったので、そのときに学習した内容で需要がありそうな開発環境に関して書いていきます。 概要 Laravel sailでDocker環境を構築して、Breezeでログインまで行っていきます。基本的には公式ドキュメントを参考にし、便利なもののインストールや日本語化は行いますが、不必要な場合は飛ばしてください。チーム開発のことも考え、GitHubにpush後cloneしてからの扱い方まで考慮していきます。 実行環境 macOS Big Sur バージョン 11.5.2 docker desktop バージョン 4.1.1(インストールしていて、起動している前提) Laravelプロジェクト作成 Laravel Sailを使用していく。 Laravel Sailは、LaravelのデフォルトのDocker構成と、操作するための軽量のコマンドラインインターフェイスです。 Sailは、Dockerの経験がなくても、PHP、MySQL、Redisを使用してLaravelアプリケーションを構築するために良い出発点を提供しています。 利用可能なサービスは、mysql、pgsql、mariadb、redis、memcached、meilisearch、minio、selenium、mailhogになっており、withというクエリ文字列変数で選択する。 docker imageやプロジェクトに必要なファイルをインストール 今回はmysqlを選択し、アプリ名はexample-appを使用する。インストールには結構時間がかかるので気長に待ち、最後にmacのパスワードだけ聞かれるので入力しましょう。 # curl -s "https://laravel.build/アプリ名?with=サービス名,サービス名" | bash curl -s "https://laravel.build/example-app?with=mysql" | bash cd example-app # gitの管理下に入れたい場合のみ git init 参考: https://readouble.com/laravel/8.x/ja/installation.html 環境変数(.env)のファイルをお好みで変更 docker-compose.ymlにAPP_PORTという環境変数が指定されている(デフォルトだと80番)ので、自分のPCで使っていないポート番号を追記する。 お好みでAPP_NAME(アプリ名)やDB_DATABASE(データベース名)、DB_USERNAME(データベースのユーザー名)、DB_PASSWORD(データベースのパスワード)も変更してください。今回は特に変更せず、デフォルトのままで行う。 APP_NAME=Laravel APP_ENV=local APP_KEY=base64:mwWgIvS9K4seI+GQ+F7DOslToBuIRgw7ibXje8A9etI= APP_DEBUG=true APP_URL=http://example-app.test APP_PORT=8000 # 追記(http://localhost:8000/ で接続) # 以下省略 言語設定(config/app.php) 'fallback_locale' => 'en'は変更しなくてよい 大文字小文字を気をつける // 変更前 // 'timezone' => 'UTC', // 変更後(タイムゾーンを東京に変更) 'timezone' => 'Asia/Tokyo', // 変更前 // 'locale' => 'en', // 変更後(言語を日本語に変更) 'locale' => 'ja', // 変更前 // 'faker_locale' => 'en_US', // 変更後(ダミーデータを日本語に変更) 'faker_locale' => 'ja_JP', phpMyAdminを導入(docker-compose.yml) ※任意 データベースをGUIからも扱うためのもので、テーブルやどんなデータが入っているかをひと目で確認できたり、簡単にデータを挿入・変更・削除したりできて便利。 mariadbなどを使用している場合はphpmyadminのdepend_onの部分のmysqlをmariadbなどに変更する # For more information: https://laravel.com/docs/sail version: '3' services: laravel.test: build: context: ./vendor/laravel/sail/runtimes/8.0 dockerfile: Dockerfile args: WWWGROUP: '${WWWGROUP}' image: sail-8.0/app extra_hosts: - 'host.docker.internal:host-gateway' ports: - '${APP_PORT:-80}:80' environment: WWWUSER: '${WWWUSER}' LARAVEL_SAIL: 1 XDEBUG_MODE: '${SAIL_XDEBUG_MODE:-off}' XDEBUG_CONFIG: '${SAIL_XDEBUG_CONFIG:-client_host=host.docker.internal}' volumes: - '.:/var/www/html' networks: - sail depends_on: - mysql mysql: image: 'mysql/mysql-server:8.0' ports: - '${FORWARD_DB_PORT:-3306}:3306' environment: MYSQL_ROOT_PASSWORD: '${DB_PASSWORD}' MYSQL_ROOT_HOST: "%" MYSQL_DATABASE: '${DB_DATABASE}' MYSQL_USER: '${DB_USERNAME}' MYSQL_PASSWORD: '${DB_PASSWORD}' MYSQL_ALLOW_EMPTY_PASSWORD: 1 volumes: - 'sailmysql:/var/lib/mysql' networks: - sail healthcheck: test: ["CMD", "mysqladmin", "ping", "-p${DB_PASSWORD}"] retries: 3 timeout: 5s # 追記 phpmyadmin: image: phpmyadmin/phpmyadmin restart: always environment: PMA_ARBITRARY: 1 PMA_HOST: "${DB_HOST}" PMA_USER: "${DB_USERNAME}" PMA_PASSWORD: "${DB_PASSWORD}" ports: - 8080:80 volumes: - ./infra/docker/phpmyadmin/sessions:/sessions networks: - sail depends_on: - mysql networks: sail: driver: bridge volumes: sailmysql: driver: local エラーメッセージの日本語化 ※任意 デフォルトの英語のままでOKなら飛ばす 公式にもエラーメッセージの日本語化があるが、既にカスタムされているものを今回は使用。 次ののURLにアクセスし「https://github.com/Laravel-Lang/lang 」 ダウンロードしてくる ダウンロードしてきたlang/localesの中のjaを自分のプロジェクトのresources/langの直下に入れる。 自分のプロジェクトのresources/lang/jaの中のja.jsonを上の階層resources/lang直下に移動 補足: https://readouble.com/laravel/8.x/ja/validation-php.html コンテナを起動 docker compose up -dと同じような意味 ./vendor/bin/sail up -d 「 http://localhost:8000/ 」でlaravel、「 http://localhost:8080/ 」でphpMyAdminが起動した状態になる laravel-debugbarのインストール ※任意 デバッグをするときに便利なので入れる docker compose exec laravel.test bashでもコンテナに入れる # コンテナ内に入る ./vendor/bin/sail bash # インストール composer require barryvdh/laravel-debugbar --dev Laravel Breezeのインストール 認証に必要なので入れる Laravel Breezeにログイン、ユーザー登録、パスワードのリセット、メールの検証、パスワードの確認など、Laravelのすべての認証機能を最小限シンプルに実装しました。Laravel Breezeのデフォルトビュー層は、Tailwind CSSでスタイルを設定したシンプルなBladeテンプレートで構成しています。 # コンテナ内で実行 composer require laravel/breeze --dev php artisan breeze:install # tailwind cssなどを使用しているため必要 npm install && npm run dev # usersテーブルなどのマイグレーションを実行 php artisan migrate これで右上のRegisterのリンクからユーザ登録ができるようになった。 GitHubにpushしたものをcloneしてからの流れ チーム開発のときなどにGithubを使用すると思うが、そのときに注意点がある。 .gitingnoreに/vendorと書かれているので、コマンド時に使用していた./vendor/bin/sailが使用できない。/vendor/bin/sailはcurlを使用したときに現れたものである。 対策としては公式に書かれている。 PHPとComposerを含む小さなDockerコンテナを使用して、アプリケーションの依存関係をインストールする必要がある。 GitHubからcloneする git clone リポジトリURL # cloneしてきたプロジェクトに移動 cd example-app 環境変数(.env)を作成 GitHubには.envはpushされないようになっているので、まずは.env.exampleの中身をコピーして.envファイルを作成してから貼り付ける DB_CONNECTIONとDB_HOSTは使用しているデータベース名(今回はmysql)を記述し、DB_PASSWORDも設定(今回はpassword)。 APP_NAME、APP_PORT、DB_DATABASE、DB_USERNAMEはお好みで記述。 APP_NAME=Laravel APP_ENV=local # APP_KEYはエラーが出たときにコマンドで生成 APP_KEY= APP_DEBUG=true APP_URL=http://localhost # 書かなければ80になる APP_PORT=8000 LOG_CHANNEL=stack LOG_DEPRECATIONS_CHANNEL=null LOG_LEVEL=debug # mysqlを使用 DB_CONNECTION=mysql # mysqlに変更 DB_HOST=mysql DB_PORT=3306 DB_DATABASE=example_app # userに変更 DB_USERNAME=user # passwordに変更 DB_PASSWORD=password # これより下は変更なし BROADCAST_DRIVER=log CACHE_DRIVER=file FILESYSTEM_DRIVER=local QUEUE_CONNECTION=sync SESSION_DRIVER=file SESSION_LIFETIME=120 MEMCACHED_HOST=127.0.0.1 REDIS_HOST=127.0.0.1 REDIS_PASSWORD=null REDIS_PORT=6379 MAIL_MAILER=smtp MAIL_HOST=mailhog MAIL_PORT=1025 MAIL_USERNAME=null MAIL_PASSWORD=null MAIL_ENCRYPTION=null MAIL_FROM_ADDRESS=null MAIL_FROM_NAME="${APP_NAME}" AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_DEFAULT_REGION=us-east-1 AWS_BUCKET= AWS_USE_PATH_STYLE_ENDPOINT=false PUSHER_APP_ID= PUSHER_APP_KEY= PUSHER_APP_SECRET= PUSHER_APP_CLUSTER=mt1 MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}" MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}" コンテナを起動する /vendorやdockerのイメージをインストール (dockerデスクトップは起動している前提でfishを使用している場合はzshやbashに切り替える) docker run --rm \ -u "$(id -u):$(id -g)" \ -v $(pwd):/var/www/html \ -w /var/www/html \ laravelsail/php80-composer:latest \ composer install --ignore-platform-reqs ./vendor/bin/sail up -d http://localhost:8000/ にアクセスすると、No application encryption key has been specified.というエラーが出るのでAPP_KEYを作成。 # コンテナに移動 ./vendor/bin/sail bash # APP_KEYを作成 php artisan key:generate npm install && npm run dev php artisan migrate http://localhost:8080/ にアクセスすると、テーブルができているのが確認できる。 以上でcloneをしてからログインまで完了! 参考: https://readouble.com/laravel/8.x/ja/sail.html

本記事は、サムザップ Advent Calendar 2021 の12/4の記事です。 はじめに はじめまして、サムザップの北島です。 突然ですが、Google Apps Script（以降、GAS）で色々している皆さん！ GASは便利ですが、ブラウザのエディター上で開発するのはちょっと大変ですよね。 そこで、今回は Docker + Clasp で開発環境を作りつつ、さらに Jest + GitHub Actions でテストもしてしまえ！という内容です。 というわけで、Docker、Clasp、Jest、GitHub Actionsと、4つについてそれぞれ書いていきます。 が、詳しく書いていくとかなり長くなってしまうため、今回はポイントを絞って簡潔にという感じにしております、ご了承ください。 開発環境 まず、今回作る開発環境の構成は以下になります。 | - gas | | - .github | | | - workflows | | | | - ci.yml | | - .docker | | | - Dockerfile | | | - docker-compose.yml | | - src | | | - package.json | | | - babel.config.js | | | - node_modules | | | - hoge | | | | - .clasp.json | | | | - .claspignore.json | | | | - appsscript.json | | | | - hoge.ts | | | | - __test__ | | | | | - hoge.test.ts Docker では、Docker環境の構築についてです。 Dockerをインストールした状態で、以下のファイルを用意してください。 なお、後に出てくる Clasp、Jest の設定もここでしてしまいます。 .docker/Dockerfile FROM node:16.4.1 RUN npm i @google/clasp -g .docker/docker-compose.yml version: '3' services: gas: build: . tty: true container_name: 'gas-container' volumes: - ../src/:/opt/ working_dir: /opt src/package.json { "dependencies": { "@google/clasp": "^2.4.1", "google-spreadsheet": "^3.1.15", "npm": "^7.20.6" }, "devDependencies": { "@babel/cli": "^7.14.8", "@babel/core": "^7.15.0", "@babel/plugin-transform-modules-commonjs": "^7.15.0", "@babel/preset-env": "^7.15.0", "jest": "^27.0.6", "jest-junit": "^12.2.0" }, "jest": { "globals": { "SpreadsheetApp": {} } } } src/babel.config.js module.exports = { presets: [ [ '@babel/preset-env', { targets: { node: 'current', }, } ] ], plugins: [ '@babel/plugin-transform-modules-commonjs', ] } 用意ができたら、以下のコマンドで環境を立ち上げることができます。 初回のみ $ cd .docker $ docker-compose build --no-cache $ docker-compose up -d $ docker-compose ps ※以下があることを確認 Name Command State Ports ----------------------------------------------------- gas-container docker-entrypoint.sh node Up （停止するときは以下） $ docker-compose down 初回以降 $ cd .docker $ docker-compose up -d （停止するときは以下） $ docker-compose down Clasp 続いて、Claspについてです。 Claspは、Google が提供するGASをローカルで管理できるようになるツールになります。 素直にGASの開発を行うと、ブラウザ上のエディターにコードを書くことになりますが、Claspを使うとローカルで書いたものを clasp push で簡単に反映できるようになります。 上記のDocker環境を立ち上げた状態で以下を実行します。 $ docker-compose exec gas bash $ npx clasp login --no-localhost ※URLが表示されるのでブラウザでアクセスしGoogleアカウントでログイン ※codeが表示されるのでコピペ これにより .docker/.clasprc.json が作成され、以降はGoogleへのログインが不要になります。 次に .clasp.json を用意します。 src/hoge/.clasp.json { "scriptId":"【管理したいGASのID】" } Claspで管理したいGASは予め作成しておいてください。 これで以下のコマンドが実行可能になります。 $ npx clasp pull GASに反映されているコードをローカルに持ってきます $ npx clasp open GASをブラウザで開きます $ npx clasp push ローカルのコードをGASに反映します ローカルでの開発が可能になりましたね！ Jest 続いて、Jestです。 Jestのインストールは以下でできます。 $ docker-compose exec ikusa-gas bash $ npm install --save-dev jest Jestを使うことで、GASのテストコードを書くことができます。 コードは __test__ 配下に置くか、ファイル名を hoge.test.ts とします。 テストするコードのサンプル（src/hoge/hoge.ts） /* * 足し算 */ function plus(a, b) { return add(a, b); } /* * スプレットシートの範囲を指定して取得、配列で返す */ function getSheetAsArray(ssUrl, ssName, startRow, endRow, startColumn, endColumn) { var sheet = SpreadsheetApp.openByUrl(ssUrl+"\/").getSheetByName(ssName); var result = sheet.getRange(startRow, startColumn, endRow-startRow+1, endColumn-startColumns+1).getValues(); return result; } テストコードのサンプル（src/hoge/__test__/hoge.test.ts） import {plus, getSheetAsArray} from '../hoge.ts'; // モックの例 SpreadsheetApp.openByUrl = jest.fn(() => ({ getSheetByName: jest.fn(() => ( { getRange: jest.fn(() => ( { getValues: jest.fn(() => [ ["HEAD1", "HEAD2", "HEAD3"], ["A1", "B1", "C1"], ["A2", "B2", "C2"], ]), } )), } )), })); // テストの例 describe('テスト', () => { it('plus', () => { var result = plus(2, 3); expect(result).toEqual(5); }); it('# getSheetAsArray', () => { var output = getSheetAsArray(); expect(output[0][0]).toBe("HEAD1"); expect(output[0][1]).toBe("HEAD2"); expect(output[0][2]).toBe("HEAD3"); expect(output[1][0]).toBe("A1"); expect(output[1][1]).toBe("B1"); expect(output[1][2]).toBe("C1"); expect(output[2][0]).toBe("A2"); expect(output[2][1]).toBe("B2"); expect(output[2][2]).toBe("C2"); }); }); こんな感じで簡単にテストが書けます。 GAS開発の場合、スプレットシートを使うことが多いと思います。 スプレットシートを操作するような関数は、上記のようにモック化すると良いと思います。 テストを実行する方法は以下のとおりです。 すべてのテストを実行する場合 $ docker-compose exec gas npx jest 管理するGASが複数になり、特定のテストだけを実行する場合 例）src/hoge2 配下のテストを実行する場合 $ docker-compose exec gas npx jest --verbose hoge2 なお、テストコードはGASに上げる必要はないので .claspignore を設定すると良いです。 src/hoge/.claspignore __test__/* GitHub Actions 最後に、GitHub Actionsについてです。 上記ではテストを手動で実行しましたが、GitHub Actionsを使うことで自動で実行することができます。 （GASのコードをGitHubでバージョン管理している前提です。） masterブランチへのプルリクが作成されたタイミングでテストを実行したい場合を例として載せておきます。 .github/workflows/ci.yml name: CI on: pull_request: branches: [ master ] jobs: build: runs-on: ubuntu-latest steps: - name: git clone uses: actions/checkout@v1 - name: Instal node uses: actions/setup-node@v1 with: node-version: '16.4.1' - name: Install npm run: npm install -g npm@7.18.1 - name: Install jest run: npm install --save-dev jest working-directory: ./src - name: Install babel run: npm install --save-dev @babel/core @babel/cli @babel/preset-env @babel/plugin-transform-modules-commonjs working-directory: ./src - name: Run test run: npx jest working-directory: ./src まとめ というわけで、今回は Docker + Clasp + Jest + GitHub Actions でGAS開発をモリモリにする方法を紹介しました。 日頃、GASで開発をしている皆さんの参考になれば嬉しいです。 以上、サムザップ Advent Calendar 2021 の12/4の記事でした。 明日は @fuzy さんの記事です、お楽しみに！

[概要] ①Dockerインストール編の後続記事となります。 　Dockerインストール編 Dockerをインストールした後。Dockerファイルを作成してみよう！ [作業] 作業用フォルダの作成 Dockerファイルを作成する前に、作業用フォルダを作ろう。 1, Finderを開いて、ユーザーディレクトリに、[LocalServer]フォルダを作成 2, [LocalServer]直下に、[app]フォルダも、ついでに作成 ※フォルダ名は任意 Dockerファイルとは Dockerファイルとは、大きく2点を理解できればとりあえずはOKなのかなとは思います。 [Dockerイメージ] Dockerイメージとは、Dockerコンテナを作る上で必要なファイル群である。 Dockerイメージは、以下にゴロゴロ落ちています。 docker hub 今回は、このDockerイメージを使用して、Dockerコンテナを作成することが目的です。 ※Dockerイメージは自身で作成することも可能 ※今回使用するのは、Dockerイメージ「python:3.7.4」 [Dockerコンテナ] Dockerコンテナとは、Dockerイメージを元に作成されるものとなります。 イメージとしては、コンテナという大きな箱に必要な複数のイメージファイルが入っている。 <大まかな流れ> 1, Dockerイメージを定義 2, Dockerイメージを元に、コンテナを作成 3, 上記コンテナを用途に合わせて「起動・停止」する Dockerファイルの作成 1, テキストファイルで、ファイル名「Dockerfile」を以下の内容で作成する。 FROM python:3.7.4 ARG project_dir=/app/ WORKDIR $project_dir RUN pip install flask CMD [“python” “local_server.py”] <定義命令> FROM：ベースとなるDockerイメージの指定 ARG：dockerfile内で使用できる変数を定義できる 　　　※使ってみた WORKDIR：作業用ディレクトリを指定　 　　　　　　※指定しない場合はroot直下が指定される RUN：コンテナビルド時に、コンテナ内でコマンドを実行する 　　　[pip install flask]は、Flaskをインストールするためのコマンドであり 　　　※Flaskは、「PythonのWebアプリケーションフレームワーク」である CMD：コンテナのデフォルトの実行コマンドを定義する 2, 上記ファイルを作成したら、[localServer]フォルダ直下に保存しよう。 LocalServer / Dockerfile [参考] ・ https://blog.codecamp.jp/programming-docker-image-container ・ https://programing-school.work/docker-image/

[概要] ①Dockerインストール編の後続記事となります。 　Dockerインストール編 Dockerをインストールした後。Dockerファイルを作成してみよう！ [作業] 作業用フォルダの作成 Dockerファイルを作成する前に、作業用フォルダを作ろう。 1, Finderを開いて、ユーザーディレクトリに、[LocalServer]フォルダを作成 2, [LocalServer]直下に、[app]フォルダも、ついでに作成 ※フォルダ名は任意 Dockerファイルとは Dockerファイルとは、大きく2点を理解できればとりあえずはOKなのかなとは思います。 [Dockerイメージ] Dockerイメージとは、Dockerコンテナを作る上で必要なファイル群である。 Dockerイメージは、以下にゴロゴロ落ちています。 docker hub 今回は、このDockerイメージを使用して、Dockerコンテナを作成することが目的です。 ※Dockerイメージは自身で作成することも可能 ※今回使用するのは、Dockerイメージ「python:3.7.4」 [Dockerコンテナ] Dockerコンテナとは、Dockerイメージを元に作成されるものとなります。 イメージとしては、コンテナという大きな箱に必要な複数のイメージファイルが入っている。 <大まかな流れ> 1, Dockerイメージを定義 2, Dockerイメージを元に、コンテナを作成 3, 上記コンテナを用途に合わせて「起動・停止」する Dockerファイルの作成 1, テキストファイルで、ファイル名「Dockerfile」を以下の内容で作成する。 FROM python:3.7.4 ARG project_dir=/app/ WORKDIR $project_dir RUN pip install flask CMD [“python” “local_server.py”] <定義命令> FROM：ベースとなるDockerイメージの指定 ARG：dockerfile内で使用できる変数を定義できる 　　　※使ってみた WORKDIR：作業用ディレクトリを指定　 　　　　　　※指定しない場合はroot直下が指定される RUN：コンテナビルド時に、コンテナ内でコマンドを実行する 　　　[pip install flask]は、Flaskをインストールするためのコマンドであり 　　　※Flaskは、「PythonのWebアプリケーションフレームワーク」である CMD：コンテナのデフォルトの実行コマンドを定義する 2, 上記ファイルを作成したら、[localServer]フォルダ直下に保存しよう。 LocalServer / Dockerfile [参考] ・ https://blog.codecamp.jp/programming-docker-image-container ・ https://programing-school.work/docker-image/

[概要] ①Dockerインストール編の後続記事となります。 　Dockerインストール編 Dockerをインストールした後。Dockerファイルを作成してみよう！ [作業] 作業用フォルダの作成 Dockerファイルを作成する前に、作業用フォルダを作ろう。 1, Finderを開いて、ユーザーディレクトリに、[LocalServer]フォルダを作成 2, [LocalServer]直下に、[app]フォルダも、ついでに作成 ※フォルダ名は任意 Dockerファイルとは Dockerファイルとは、大きく2点を理解できればとりあえずはOKなのかなとは思います。 [Dockerイメージ] Dockerイメージとは、Dockerコンテナを作る上で必要なファイル群である。 Dockerイメージは、以下にゴロゴロ落ちています。 docker hub 今回は、このDockerイメージを使用して、Dockerコンテナを作成することが目的です。 ※Dockerイメージは自身で作成することも可能 ※今回使用するのは、Dockerイメージ「python:3.7.4」 [Dockerコンテナ] Dockerコンテナとは、Dockerイメージを元に作成されるものとなります。 イメージとしては、コンテナという大きな箱に必要な複数のイメージファイルが入っている。 <大まかな流れ> 1, Dockerイメージを定義 2, Dockerイメージを元に、コンテナを作成 3, 上記コンテナを用途に合わせて「起動・停止」する Dockerファイルの作成 1, テキストファイルで、ファイル名「Dockerfile」を以下の内容で作成する。 FROM python:3.7.4 ARG project_dir=/app/ WORKDIR $project_dir RUN pip install flask CMD [“python” “local_server.py”] <定義命令> FROM：ベースとなるDockerイメージの指定 ARG：dockerfile内で使用できる変数を定義できる 　　　※使ってみた WORKDIR：作業用ディレクトリを指定　 　　　　　　※指定しない場合はroot直下が指定される RUN：コンテナビルド時に、コンテナ内でコマンドを実行する 　　　[pip install flask]は、Flaskをインストールするためのコマンドであり 　　　※Flaskは、「PythonのWebアプリケーションフレームワーク」である CMD：コンテナのデフォルトの実行コマンドを定義する 2, 上記ファイルを作成したら、[localServer]フォルダ直下に保存しよう。 LocalServer / Dockerfile [参考] ・ https://blog.codecamp.jp/programming-docker-image-container ・ https://programing-school.work/docker-image/

Kubebuilder は Kubernetes のカスタムコントローラを作成するための支援ツールです。 カスタムコントローラを作成する上でデファクトとなりつつあるツールですが、M1 Mac(Apple Silicon) 向けのバイナリは現在リリースされていません。 そこで M1 Mac でも Kubebuilder を利用するため、Docker イメージを作成します。 本記事で作成したイメージは Docker Hub にも公開しています。 Dockerfile kubebuilder をコンテナ上で動かすため、golang のイメージをもとに kubebuilder をインストールしていきます。 kubebuilder の利用に bash, make, gcc が必要なので、追加でインストールしておきます。 Dockerfile FROM golang:1.17.3-alpine WORKDIR /workspace RUN apk add --no-cache bash make gcc libc-dev ENV KUBEBUILDER_VERSION v3.2.0 RUN wget -O /usr/local/bin/kubebuilder https://github.com/kubernetes-sigs/kubebuilder/releases/download/$KUBEBUILDER_VERSION/kubebuilder_$(go env GOOS)_$(go env GOARCH) && \ chmod +x /usr/local/bin/kubebuilder ENTRYPOINT [ "kubebuilder" ] Dockerfile を用意したら、イメージをビルドします。 Dockerfile を配置したディレクトリで以下コマンドを実行。 $ docker build -t hitsumabushi845/kubebuilder:3.2.0 . 利用方法例 引数で実行したいコマンドを叩きます。プロジェクトの初期化だと以下のようになります。 通常はディレクトリ名がプロジェクト名になるのですが、マウントしていることで正しいディレクトリ名が取れないので、--project-name でディレクトリ名を指定しています。 bash $ mkdir -p sample-project $ cd sample-project $ docker run -it --rm \ -v $(pwd):/workspace \ hitsumabushi845/kubebuilder:3.2.0 \ init --domain hitsumabushi845.github.io --repo sample-project --project-name $(pwd | xargs basename) プロジェクト作成後の make コマンドの実行はおおむねローカルでも行えます。 プロジェクト作成時に、./bin に controller-gen などのバイナリが格納されていますが、こちらはコンテナ向けのの（linux 向けの）バイナリになっているので、初めて実行する際は rm -rf ./bin などで削除してから実行します。

経緯 Docker で動かしている バックエンドアプリのログを ElasticSearch + Kibana で閲覧したくなった (ElasticSearch + Kibana の構築手順はここでは述べない) ElasticSearch のログ収集といえば fluentd だが、fluentd より軽量らしい fluent-bit を採用してみた 対応 公式ドキュメントを見て作成 バックエンドアプリコンテナがあるサーバに fluent-bit の Docker コンテナを稼働させるようにする fluent-bit が待ち受け状態になったことを確認したら、ログを送信するバックエンドアプリの方にも fluent-bit にログを送る設定を仕込む 構成 fluent-bit の設定 parser で json を指定すると、json で出力したアプリログを ElasticSearch に JSON オブジェクトとして登録してくれる 逆に指定しないと String として登録されてしまう ローカル環境で試験的に試したものなので、本番環境に採用するときは適宜変えてください / ├ docker-compose.yml ├ fluent-bit.conf └ parsers.conf docker-compose.yml version: '3.7' services: fluentd: image: fluent/fluent-bit:1.8.8-debug # docker exec で コンテナの中に入りたければデバッグバージョンが必要 container_name: fluent-bit ports: - "24224:24224" # ポート固定を指定 volumes: # テストのためボリュームマウント - type: bind source: "./fluent-bit.conf" target: "/fluent-bit/etc/fluent-bit.conf" - type: bind source: "./parser.conf" target: "/fluent-bit/etc/parser.conf" # バックエンドアプリとネットワークを合わせる networks: - "my-network" networks: my-network: external: name: my-network fluent-bit.conf [SERVICE] Flush 1 Grace 30 Log_Level debug Parsers_File /fluent-bit/etc/parsers.conf [INPUT] Name forward Listen 0.0.0.0 Port 24224 [FILTER] Name parser Match * Key_Name log Parser docker [OUTPUT] Name es Host my.elasticsearch.server HTTP_User elastic HTTP_Passwd mypassword Port 443 Type doc tls On Generate_ID On Logstash_Format On Logstash_Prefix my-backend Logstash_DateFormat %Y-%m-%d Include_Tag_Key On parsers.conf [PARSER] Name docker Format json Time_Key timestamp Time_Format %Y-%m-%dT%H:%M:%S.%L%Z バックエンドアプリの設定 ロギングドライバーを fluent-bit に設定する 注意点 fluent-bit の待ち受け TCP ポートを固定にしているので、ECS や K8S に転用すると、ローリングアップデートが出来ない問題があり ホスト名指定にしてやれば上手くいくと思われる docker コマンドで起動する場合 log-driver オプション 及び log-opt オプションを付けて起動 docker container run \ --log-driver=fluentd \ --log-opt fluentd-address=localhost:24224 \ --log-opt tag=docker.{{.Name}} \ my-image docker-compose で起動する場合 logging 項目に記載する version: "3.7" services: my-api: container_name: my-api logging: driver: "fluentd" options: fluentd-address: "localhost:24224" tag: "docker.{{.Name}}" restart: always networks: - "my-network" networks: my-network: external: name: my-network Kibana で Index を登録し確認できれば OK

概要 シェル上で docker ps や docker kill コマンドの実行にあたり、 $(コマンド) という書き方（コマンド置換）を使うと、操作が簡単になる場合があります。たとえば、複数のコンテナをまとめて停止するためには、 docker ps を実行後に docker kill 35e 1f5 ... を実行する手順が必要ですが、これを docker kill $(docker ps -q) だけで済ませます。 前提条件 Linux や macOS 上のシェル環境で利用できます。 Windows は PowerShell や WSL でのみ。コマンドプロンプトでは利用できません。 コマンド置換とは あるコマンドを実行する時、そのコマンドの中で $(コマンド) の書き方をすると、それを別のコマンド出力に置き換えられる書き方が、コマンド置換（command substitution）です。 たとえば ls コマンドを実行すると $ ls file1 file2 このようにファイル一覧が出ます。 これを、コマンド置換を使えば、次のように書き換えできます。 $ echo $(ls) file1 file2 ポイントは $(ls) の記述とは、 ls コマンドの表示結果（ file1 file2 ）を $(ls) 文字で置き換えられ、結果的に echo file1 file2 を実行したのと同じ結果となります。 $ echo file1 file2 file1 file2 なお、 `コマンド` のようにバッククォート文字で囲む書き方もあります（例： `docker ps -q`）。ただし、こちらはコマンド部分に ` を含められないレガシー（旧来形式）の書き方です。 Docker でコマンド置換を活用 コマンド置換を docker コマンドで使うと、以下のような作業が簡単になります。 直前に作成した docker コンテナを直ちに操作する 実行中の Docker コンテナをすべて停止する Docker コンテナやイメージを全削除する また、CI 環境などで、シェルスクリプトを利用した処理の自動化にも、このコマンド置換が利用できます。 直前に作成した Docker コンテナを直ちに操作する Docker コンテナの起動直後、対象のコンテナに docker logs でログ（標準出力やエラー）を見たいときや、docker exec を使ったり、 docker top で実行中のプロセスを表示したい場合があります。 通常であれば、2つのステップが必要です。 何らかの方法で、コンテナ ID またはコンテナ名を知る docker コマンドで、コンテナ ID かコンテナ名で、対象のコンテナを操作する たとえば、 docker logs コマンドでログを見るには docker logs interesting_sanderson のようにコンテナ名（この例では interesting_sanderson）、あるいは、コンテナIDを指定する必要があります。つまり、コンテナの操作には、何らかの方法で事前にコンテナ ID かコンテナ名を知っておかなくてはいけません。 ちなみに、この課題を簡単に解決するのは、 docker run --name コンテナ名 を使い、コンテナに予め名前を与える方法です。1つの Docker ホスト上で、コンテナ名を重複して実行できません。そうしておけば、シェルスクリプト上でも、間違いなくコマンドが実行できます。しかし、この方法では、同じコンテナ名で同時に処理が出来ないため、意図せず自動実行できない場合や、それを回避するための工夫が必要になる場合も考えられます。 ですが、このような方法を使わなくても、コマンド置換を使えば、直前に操作したコンテナIDを直ちに知れます。 例として、Nginx コンテナをデタッチドモード（バックグラウンド）で実行するケースを取り上げます。 $ docker run -itdP nginx 0c28d6afc0f9ba9a1f73ae7769493c437bba8583fb2c769df6ba2cb4c2202381 $ デタッチドモードであれば、コマンド実行直後に 0c28d.... で始まるコンテナ ID が表示されています。 通常、ここでログを見ようとすると docker logs 0c28 のように入力しますが、コマンド置換を使えば docker logs $(docker ps -lq) という決まり切ったコマンドで表示できます。 $ docker logs $(docker ps -lq) /docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration /docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/ /docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh 10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf 10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf /docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh /docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh /docker-entrypoint.sh: Configuration complete; ready for start up 2021/11/30 22:36:25 [notice] 1#1: using the "epoll" event method （省略） ここで何をしているかを知るには、 $(コマンド) にあたる docker ps -lq の理解が欠かせません。 まず、 docker ps -l コマンドは docker ps --lastest の省略系で、 -l オプションは、直近に作成したコンテナ（状態が、起動・停止かに拘わらず）を表示します。 $ docker ps -l CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0c28d6afc0f9 nginx "/docker-entrypoint.…" 6 minutes ago Up 6 minutes 0.0.0.0:49158->80/tcp, :::49158->80/tcp keen_stonebraker そして docker ps -l -q は docker ps --lastest --quiet の省略系で、 -q オプションはコンテナ ID しか表示しません。 $ docker ps -l -q 0c28d6afc0f9 つまり、 docker logs $(docker ps -lq) の実行とは、この例における docker logs 「コマンドdocker ps -lqの実行結果」 であり、 $( ) で囲まれた部分は実行した出力に置換されますから、結果的に docker logs 0c28d6afc0f9 を実行するのと、同じ処理を意味します。 この方法を使えば、直前に操作したコンテナ ID が分からなくても、手動でコマンドを実行して確認しなくても操作できます。さらに、シェルスクリプトなど、自動的にコンテナ操作をしたい場合にも有用です。 実行中の Docker コンテナをすべて停止する 次のように、複数の Docker コンテナが起動している状態があるとします。 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0c28d6afc0f9 nginx "/docker-entrypoint.…" 12 minutes ago Up 12 minutes 0.0.0.0:49158->80/tcp, :::49158->80/tcp keen_stonebraker 35ecc5c7355b nginx "/docker-entrypoint.…" 3 months ago Up 3 months 0.0.0.0:49157->80/tcp, :::49157->80/tcp inspiring_merkle e6b88055e48c nginx "/docker-entrypoint.…" 3 months ago Up 3 months 0.0.0.0:49156->80/tcp, :::49156->80/tcp quirky_mirzakhani 1f51ba1a4dfd nginx "/docker-entrypoint.…" 3 months ago Up 3 months 0.0.0.0:49155->80/tcp, :::49155->80/tcp determined_shaw 703b701ae8d3 nginx "/docker-entrypoint.…" 3 months ago Up 3 months 0.0.0.0:49154->80/tcp, :::49154->80/tcp interesting_sanderson 7f5d7a4bd06e nginx "/docker-entrypoint.…" 3 months ago Up 3 months 0.0.0.0:49153->80/tcp, :::49153->80/tcp youthful_ramanujan ここでは6つの Nginx コンテナが起動中です。これらをまとめて停止(kill)する場合を考えましょう。通常であれば、次の手順が必要です。 docker ps でコンテナ一覧を表示する（既に実行済み） docker kill で、停止したいコンテナのIDを指定する この例であれば docker kill 0c2 35e e6b 1f5 715 と入力する必要があります。 ですが、これもコマンド置換であれば、次のコマンドで済みます。 $ docker kill $(docker ps -q) 0c28d6afc0f9 e6b88055e48c 1f51ba1a4dfd 703b701ae8d3 7f5d7a4bd06e Docker コンテナをまとめて削除する 停止中のコンテナを全削除するには docker container prune コマンドがあります。個人で利用しているPC上で、雑に停止中のコンテナ（正確には、コンテナ用のイメージレイヤやログや設定情報）を一括削除するには楽ですが、社内や学内の共用環境で実行するのは躊躇します。 そういう場合でも、コマンド置換と docker ps のフィルタによって問題を解決できます。 doker ps では -f または --filter オプションによって（ リファレンス ）、status や 元イメージの情報によるフィルタができます。 たとえば、 alpine:latest イメージを使ったコンテナ一覧は次のようになります（ -a オプションの追加により、起動・停止中に拘わらず、すべてを表示）。 $ docker ps -a -f ancestor=alpine:latest CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6873bcaf4879 alpine "/bin/sh" 2 hours ago Exited (137) 2 hours ago hardcore_tu b5c731e558f7 alpine "/bin/sh" 2 hours ago Exited (137) 2 hours ago clever_antonelli fa14d1f00ae7 alpine "/bin/ash" 3 months ago Exited (0) 3 months ago crazy_lehmann c9b814f42f7c alpine "/bin/bash" 3 months ago Created pedantic_merkle これらだけを削除するには、これまで見てきた通りコマンド置換を使えば簡単です。 $ docker rm -f $(docker ps -a -f ancestor=alpine:latest -q) 6873bcaf4879 b5c731e558f7 fa14d1f00ae7 c9b814f42f7c 実際に運用している環境では、フィルタはイメージ名だけでなく、状態など組みあわせるなど、工夫が必要になる場合もあるでしょう。 Docker イメージをまとめて削除 以前であれば、このコマンド置換を使い docker rmi -f $(docker image ls -q) のように実行していましたが、最近では便利なコマンドがあります。 親子関係を持たない、不要と思われる中間イメージ（dangling images）を一括で消すコマンドは docker image prune です（ リファレンス ）。このコマンドを実行しても、Docker Hub のようなリポジトリからダウンロードしたイメージは残しておけます。 $ docker image prune WARNING! This will remove all dangling images. Are you sure you want to continue? [y/N] y Total reclaimed space: 0B $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest dd34e67e3371 3 months ago 133MB alpine latest 021b3423115f 3 months ago 5.6MB ubuntu latest 1318b700e415 4 months ago 72.8MB hello-world latest d1165f221234 9 months ago 13.3kB この環境では、もともと余分なイメージはなかったようです。 便利なのは、-a オプションの付与です。Docker コンテナで使われていないイメージを削除します。さらに、 -f オプションも付ければ確認のプロンプトも出ませんので、シェルスクリプトでの処理にも向いています。 $ docker image prune -a -f Deleted Images: untagged: hello-world:latest untagged: hello-world@sha256:0fe98d7debd9049c50b597ef1f85b7c1e8cc81f59c8d623fcb2250e8bec85b38 deleted: sha256:d1165f2212346b2bab48cb01c1e39ee8ad1be46b87873d9ca7a4e434980a7726 deleted: sha256:f22b99068db93900abe17f7f5e09ec775c2826ecfe9db961fea68293744144bd untagged: alpine:latest untagged: alpine@sha256:eb3e4e175ba6d212ba1d6e04fc0782916c08e1c9d7b45892e9796141b1d379ae deleted: sha256:021b3423115ff662225e83d7e2606475217de7b55fde83ce3447a54019a77aa2 deleted: sha256:bc276c40b172b1c5467277d36db5308a203a48262d5f278766cf083947d05466 Total reclaimed space: 5.609MB $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx latest dd34e67e3371 3 months ago 133MB ubuntu latest 1318b700e415 4 months ago 72.8MB この環境では nginx と ubuntu のコンテナが実行中のため残っていますが、それ以外の不要なイメージは削除されています。 ポイント docker で $(コマンド) によるコマンド置換を使えば、通所の作業が楽になる場合や、シェルスクリプトでのコマンド実行にも使えます。 参考 「Man page of BASH」の「コマンド置換」 https://linuxjm.osdn.jp/html/GNU_bash/man1/bash.1.html Command Substitution (Bash Reference Manual) https://www.gnu.org/software/bash/manual/html_node/Command-Substitution.html

はじめに こんにちは。 KDDIアジャイル開発センターの小板橋です。 この記事は、KDDI Engineer&Designer Advent Calendar 2021の2日目の記事となります。 先日、Amazon ECRでpull-through-cache機能が発表されました。 今回は、その機能を実際に試してみるのと、何が嬉しいのかについてまとめていこうと思います。 pull-through-cache機能とは 一言で言うならば、ユーザーのECR(Private Registry)を通して外部のパブリックイメージを透過的にpullできるようになったというものです。 これにより・・・ 1 : パブリックイメージのpullにPrivateLinkを使うことができるようになります。 2 : Docker HubやECR(Public Repository)の「Pull Rate Limit」、すなわちスロットリング回避もできます。 図解すると以下のようになります。 pull-through-cacheでは、Amazon ECR PublicおよびQuayのpull-through-cacheルールの作成をサポートしています。 外部public registryのpull-through-cacheが作成されたら、Amazon ECR private registry URIを使用して外部public registryからイメージをプルするだけで、Amazon ECRがリポジトリを作成し、そのイメージをキャッシュします。 また、もう一点便利な機能としては、24時間毎にpublic registryで公式のimageが更新されていないかチェックし、更新されていた時は自動でAmazon ECR private registryのイメージも更新してくれます。 そうして、ここでもう一つアップデートがあります。 pull-through-cacheでは、Amazon ECR PublicおよびQuayのみをサポートすることになっていますが、実は同じタイミングでDocker Hub の Docker 公式イメージが ECR Public から pull できるようになりました! 今までは・・？ 外部public registryのimage pullを直接させたくない場合や、Docker HubやECR(Public Repository)の「Pull Rate Limit」、すなわちスロットリング回避するには、下のような構成で、ユーザが定期的にAmazon ECR private registryに手動で更新する運用にならざるしかなかったのではないでしょうか。 pull-through-cacheの制約 pull-through-cacheルールの作成は、次のリージョンではサポートされていない 中国（北京）（cn-north-1） 中国（寧夏）（cn-northwest-1） AWS GovCloud（米国-東部）（us-gov-east-1） AWS GovCloud（US-West）（us-gov-west-1） Amazon ECR private registryには、最大10個のpull-through-cacheルールの作成しかできない。 Amazon ECRは外部リポジトリを24時間に1回までしかチェックしない 実際に試してみた プルスルーキャッシュ設定 pull-through-cacheから、ルールの作成を選択する。 プルスルーキャッシュルールを作成 ソースより、パブリックレジストリを今回は、「ECR Public」を選択しました。 プルスルーキャッシュ設定の確認 設定が完了すると以下のように表示されます。 これで、設定はできたのであとはプライベートリポジトリからのイメージPullを試してみます。 ちなみに、検証時はプライベートリポジトリには何もないことを確認しています。 なので、imageをPullした際に、「ECR Public」よりimageをpullされ、Amazon ECRがリポジトリを作成し、そのイメージをキャッシュするはずです。 プライベートレジストリへdocker loginする aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin xxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/ecr-public 試しにプライベートレジストリからAWS for Fluent Bit イメージをpullしてみる docker image pull xxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com/ecr-public/aws-observability/aws-for-fluent-bit:latest latest: Pulling from ecr-public/aws-observability/aws-for-fluent-bit e11e8d46e102: Pull complete 78ae343d6dcf: Pull complete f5152049901d: Pull complete 757a28787cbb: Pull complete 38488c29e0d3: Pull complete fd5c8838b80c: Pull complete 2010684db286: Pull complete d52f3ff92019: Pull complete 8057cbc0f33a: Pull complete 99ad7aff5b44: Pull complete e4759977e091: Pull complete a87998555db4: Pull complete 9ae4d994bf55: Pull complete dbcbcb0cdb88: Pull complete 1ac29bff7532: Pull complete 22646ab5a77d: Pull complete a7320d535531: Pull complete Digest: sha256:c3cf6719f9aad2e2581f0bf1f2ed69d57f25c32d227e0a66fa769271668aea60 Status: Downloaded newer image for xxxxxx.dkr.ecr.us-east-1.amazonaws.com/ecr-public/aws-observability/aws-for-fluent-bit:latest xxxxx.dkr.ecr.us-east-1.amazonaws.com/ecr-public/aws-observability/aws-for-fluent-bit:latest プライベートリポジトリの状態を確認 確認してみると、リポジトリecr-public/aws-observability/aws-for-fluent-bitが登録されていますね。 また、プルスルーキャッシュの項目が「アクティブ」になっていると、24時間毎のチェックが行われるようです。 参考文献

この記事は セゾン情報システムズ Advent Calendar 2021 1日目の記事です。 記事のタイトルは一体何を言っているんだ AWS re:Invent 2021 の Day 1 で Amazon ECR に関連する2つのアップデートがありました。 これらを合わせて使用することで Private な ECR Repository のみを使いつつ、Docker Hub のオフィシャルイメージを透過的に pull できるようになります。 Amazon ECR の Pull through cache って? 対応するパブリックコンテナイメージレジストリ上のイメージを、ECR の Private リポジトリにキャッシュできる機能です。2021/11/30 現在で Quay.io と ECR Public に登録されているイメージをキャッシュできます。 セキュリティ上の理由でパブリックなコンテナレジストリにはアクセスさせたくないが、特定のベースイメージの利用に限っては許可したいケースなどで特に嬉しい機能です。PriavateLink で ECR を利用している環境でもパブリックなイメージを透過的に pull でき、イメージに更新があった場合は自動で同期されます。 ※ 厳密には PrivateLink 環境では初回のみ NAT Gateway を経由したインターネットアクセスが必要になります。 Docker の公式イメージをキャッシュするには？ 前述の通り、Pull through cache は 現時点で Quay.io と ECR Public のみ対応しています。Docker Hub に登録されているイメージはキャッシュできませんが、Pull through cache の発表と同日に Docker の公式イメージが Amazon ECR Public 上で利用可能になったことがアナウンスされました。 つまり、ECR Public 上に登録されている Docker公式イメージを ECR のプライベートリポジトリにキャッシュすることは可能ということです。 実際にやってみます。Amazon ECR コンソールの Private registry → Pull through cache からプルスルーキャッシュ設定を追加します。 ソースのパブリックレジストリで ECR Public を選択します。送信先の名前空間は任意のものを指定できますが、ここではコンソールでデフォルトで入力されている ecr-public を使用します。 設定はこれだけです。簡単ですね！ 今回は Docker の 公式イメージを pull したいので、NGINX のイメージを例にします。Docker から配信されているイメージであることとその URL を確認します。 ECR のプライベートレジストリにログイン後、以下の形式で Pull through cache 機能を利用してイメージを pull できます。 docker pull <aws_account_id>.dkr.ecr.<region>.amazonaws.com/<name_space>/<repository_name>/<image_name>:<tag> $ aws ecr get-login-password | docker login --username AWS --password-stdin https://123456789012.dkr.ecr.us-east-1.amazonaws.com Login Succeeded $ docker pull 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/docker/library/nginx:1.21.4 1.21.4: Pulling from ecr-public/docker/library/nginx eff15d958d66: Pull complete 1e5351450a59: Pull complete 2df63e6ce2be: Pull complete 9171c7ae368c: Pull complete 020f975acd28: Pull complete 266f639b35ad: Pull complete Digest: sha256:097c3a0913d7e3a5b01b6c685a60c03632fc7a2b50bc8e35bcaa3691d788226e Status: Downloaded newer image for 664573244438.dkr.ecr.us-east-1.amazonaws.com/ecr-public/docker/library/nginx:1.21.4 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/docker/library/nginx:1.21.4 以下のようにプライベートリポジトリとしてイメージがキャッシュされていることがわかります。 Pull 可能なリポジトリを制限するには? レジストリのアクセス許可設定で制限可能です。コンソールでは簡単に Pull through cache 用のポリシーを作成できるようになっています。 ポリシータイプで pull through cache policy を選択し、任意のステートメント ID を指定します。次に許可を付与する IAM エンティティを追加し、キャッシュルールで指定した名前空間 (ここでは ecr-public) を選択します。Docker 公式イメージの pull のみを許可する場合、リポジトリ名に docker/* を指定します。 実際に作成される json のリソースポリシーは以下のような形式になります。 { "Sid": "allow-statement", "Effect": "Allow", "Principal": { "AWS": [ "<許可する IAM エンティティの ARN>" ] }, "Action": [ "ecr:CreateRepository", "ecr:BatchImportUpstreamImage" ], "Resource": [ "arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/docker/*" ] } 上記のようなレジストリのアクセス許可を設定した状態で、今度は NGINX, Inc. が提供するイメージを pull しようとすると想定通りエラーになりました。ただしエラーメッセージが does not exist なので少々わかりづらい気がしますね。 $ docker pull 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/nginx/nginx:1.21.4 Error response from daemon: repository 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/nginx/nginx not found: name unknown: The repository with name 'ecr-public/nginx/nginx' does not exist in the registry with id '123456789012' Pull through cache 機能の注意点など 初回のイメージ pull 時に Pull through cache によって透過的に作成されるリポジトリは、Amazon S3 が管理する暗号化キーによって暗号化されます KMS による暗号化を行いたい場合はイメージの pull を行う前に明示的に KMS 暗号化を有効化したリポジトリを作成しておく必要があります タグのイミュータビリティもデフォルトで無効になります 有効にすると、Pull through cache によるイメージの更新が正常に行われない可能性があります PrivateLink 環境下で ECR を使用している場合、初回のイメージ pull 時のみ NAT Gateway 経由でパブリックレジストリに接続する必要があります 初回の pull 移行、Pull through cache によってイメージの更新が行われる場合は NAT Gateway は不要です ドキュメントに以下のように記述されています。 When an image is pulled using a pull through cache rule for the first time, if you've configured Amazon ECR to use an interface VPC endpoint using AWS PrivateLink then you need to create a public subnet in the same VPC, with a NAT gateway, and then route all outbound traffic to the internet from their private subnet to the NAT gateway in order for the pull to work. Subsequent image pulls don't require this. 公式ドキュメント https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html 　 簡単ですが、以上です。 参考になれば幸いです。

この記事は セゾン情報システムズ Advent Calendar 2021 1日目の記事です。 記事のタイトルは一体何を言っているんだ AWS re:Invent 2021 の Day 1 で Amazon ECR に関連する2つのアップデートがありました。 これらを合わせて使用することで Private な ECR Repository のみを使いつつ、Docker Hub のオフィシャルイメージを透過的に pull できるようになります。 Amazon ECR の Pull through cache って? 対応するパブリックコンテナイメージレジストリ上のイメージを、ECR の Private リポジトリにキャッシュできる機能です。2021/11/30 現在で Quay.io と ECR Public に登録されているイメージをキャッシュできます。 セキュリティ上の理由でパブリックなコンテナレジストリにはアクセスさせたくないが、特定のベースイメージの利用に限っては許可したいケースなどで特に嬉しい機能です。PriavateLink で ECR を利用している環境でもパブリックなイメージを透過的に pull でき、イメージに更新があった場合は自動で同期されます。 ※ 厳密には PrivateLink 環境では初回のみ NAT Gateway を経由したインターネットアクセスが必要になります。 Docker の公式イメージをキャッシュするには？ 前述の通り、Pull through cache は 現時点で Quay.io と ECR Public のみ対応しています。Docker Hub に登録されているイメージはキャッシュできませんが、Pull through cache の発表と同日に Docker の公式イメージが Amazon ECR Public 上で利用可能になったことがアナウンスされました。 つまり、ECR Public 上に登録されている Docker公式イメージを ECR のプライベートリポジトリにキャッシュすることは可能ということです。 実際にやってみます。Amazon ECR コンソールの Private registry → Pull through cache からプルスルーキャッシュ設定を追加します。 ソースのパブリックレジストリで ECR Public を選択します。送信先の名前空間は任意のものを指定できますが、ここではコンソールでデフォルトで入力されている ecr-public を使用します。 設定はこれだけです。簡単ですね！ 今回は Docker の 公式イメージを pull したいので、NGINX のイメージを例にします。Docker から配信されているイメージであることとその URL を確認します。 ECR のプライベートレジストリにログイン後、以下の形式で Pull through cache 機能を利用してイメージを pull できます。 docker pull <aws_account_id>.dkr.ecr.<region>.amazonaws.com/<name_space>/<repository_name>/<image_name>:<tag> $ aws ecr get-login-password | docker login --username AWS --password-stdin https://123456789012.dkr.ecr.us-east-1.amazonaws.com Login Succeeded $ docker pull 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/docker/library/nginx:1.21.4 1.21.4: Pulling from ecr-public/docker/library/nginx eff15d958d66: Pull complete 1e5351450a59: Pull complete 2df63e6ce2be: Pull complete 9171c7ae368c: Pull complete 020f975acd28: Pull complete 266f639b35ad: Pull complete Digest: sha256:097c3a0913d7e3a5b01b6c685a60c03632fc7a2b50bc8e35bcaa3691d788226e Status: Downloaded newer image for 664573244438.dkr.ecr.us-east-1.amazonaws.com/ecr-public/docker/library/nginx:1.21.4 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/docker/library/nginx:1.21.4 以下のようにプライベートリポジトリとしてイメージがキャッシュされていることがわかります。 Pull 可能なリポジトリを制限するには? レジストリのアクセス許可設定で制限可能です。コンソールでは簡単に Pull through cache 用のポリシーを作成できるようになっています。 ポリシータイプで pull through cache policy を選択し、任意のステートメント ID を指定します。次に許可を付与する IAM エンティティを追加し、キャッシュルールで指定した名前空間 (ここでは ecr-public) を選択します。Docker 公式イメージの pull のみを許可する場合、リポジトリ名に docker/* を指定します。 実際に作成される json のリソースポリシーは以下のような形式になります。 { "Sid": "allow-statement", "Effect": "Allow", "Principal": { "AWS": [ "<許可する IAM エンティティの ARN>" ] }, "Action": [ "ecr:CreateRepository", "ecr:BatchImportUpstreamImage" ], "Resource": [ "arn:aws:ecr:us-east-1:123456789012:repository/ecr-public/docker/*" ] } 上記のようなレジストリのアクセス許可を設定した状態で、今度は NGINX, Inc. が提供するイメージを pull しようとすると想定通りエラーになりました。ただしエラーメッセージが does not exist なので少々わかりづらい気がしますね。 $ docker pull 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/nginx/nginx:1.21.4 Error response from daemon: repository 123456789012.dkr.ecr.us-east-1.amazonaws.com/ecr-public/nginx/nginx not found: name unknown: The repository with name 'ecr-public/nginx/nginx' does not exist in the registry with id '123456789012' Pull through cache 機能の注意点など 初回のイメージ pull 時に Pull through cache によって透過的に作成されるリポジトリは、Amazon S3 が管理する暗号化キーによって暗号化されます KMS による暗号化を行いたい場合はイメージの pull を行う前に明示的に KMS 暗号化を有効化したリポジトリを作成しておく必要があります タグのイミュータビリティもデフォルトで無効になります 有効にすると、Pull through cache によるイメージの更新が正常に行われない可能性があります PrivateLink 環境下で ECR を使用している場合、初回のイメージ pull 時のみ NAT Gateway 経由でパブリックレジストリに接続する必要があります 初回の pull 移行、Pull through cache によってイメージの更新が行われる場合は NAT Gateway は不要です ドキュメントに以下のように記述されています。 When an image is pulled using a pull through cache rule for the first time, if you've configured Amazon ECR to use an interface VPC endpoint using AWS PrivateLink then you need to create a public subnet in the same VPC, with a NAT gateway, and then route all outbound traffic to the internet from their private subnet to the NAT gateway in order for the pull to work. Subsequent image pulls don't require this. 公式ドキュメント https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache.html 　 簡単ですが、以上です。 参考になれば幸いです。