20210917のdockerに関する記事は11件です。

Docker ubuntu コンテナ内に AWS CLI をインストールする

背景 ubuntu コンテナ内で AWS CLI v2 をインストールする際にハマりました。今後のためにメモとして残しておきます。 インストール 以下のコマンドを順に実行します。 sudo apt-get update sudo apt-get install ca-certificates sudo apt-get install curl sudo apt-get install unzip sudo curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" sudo unzip awscliv2.zip sudo ./aws/install -i /usr/local/aws-cli -b /usr/bin または Dockerfile に以下を記述し、イメージのビルド時にインストールします。 Dockerfile RUN sudo apt-get update && sudo apt-get install -y \ ca-certificates \ curl \ unzip \ && sudo curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" \ && sudo unzip awscliv2.zip \ && sudo ./aws/install -i /usr/local/aws-cli -b /usr/bin 参考記事
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Localstack の initScripts が完了してから 他のコンテナを起動したい @docker-compose

これは CI等 で LocalStack を使ってテストしたいが、docker-entrypoint-initaws.d に置いた init スクリプトの実行は終わってからテスト実行したい。 そんな人にオススメの適当な方法です。 ざっくりどうするか docker-compose の healthcheck を書く localstack の http://localhost:4566/health に initScripts: initialized があるかどうかを判定するようにする depends_on の condition を使う service_healthy かどうかを判定する これだけです。 サンプルコード このケースは init.sh で cloudformation を実行したあとに app を起動したいケースを想定して書いてます。 ./localstack/init/00_init.sh #!/bin/sh cd / awslocal cloudformation create-stack \ --endpoint-url http://localhost:4566 \ --stack-name test\ --template-body file://aws-cloud-formation/cf.yaml docker-compose.yml version: '3.8' services: app: build: dockerfile: Dockerfile context: . depends_on: # IDE に Array is required と怒られるかもしれませんがちゃんと動きます localstack: condition: service_healthy localstack: image: localstack/localstack volumes: - ./aws-cloud-formation:/aws-cloud-formation - ./localstack/init:/docker-entrypoint-initaws.d ports: - 4566:4566 - 4571:4571 healthcheck: # init スクリプトが完了する前に app が起動しないよう ヘルスチェックする test: ["CMD-SHELL", "curl http://localhost:4566/health | grep '\"initScripts\": \"initialized\"'"] interval: 2s start_period: 20s retries: 30 timeout: 30s まとめ 色々方法はあるようですが、割と手軽にできたかと思います。 タイミングによってうまく行かないことがある(unhealthyだったからappは起動しない)ので、 もう少し調査が必要そうですが、こうすれば大丈夫!/これで問題ないよ!など知見のある方コメント頂けますとです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Windows 環境での docker-compose ビルドの際、Dockerfile の読込に失敗する

結構ハマったが、エラーメッセージでヒットするページが無かったので残しておく。 環境 Windows10 Pro 64bit エラー内容 例として docker-compose.yml 及び Dockerfile は最低限の内容。 docker-compose.yml version: '3' services: app: build: ./Dockerfile Dockerfile FROM php:7.4-apache C:\dev\tutorial-docker>docker-compose up -d Creating network "tutorial-docker_default" with the default driver Building app [+] Building 0.1s (1/2) => ERROR [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 90B 0.0s ------ > [internal] load build definition from Dockerfile: ------ failed to solve with frontend dockerfile.v0: failed to read dockerfile: error from sender: walk \\?\C:\dev\tutorial-docker\Dockerfile: The system cannot find the path specified. ERROR: Service 'app' failed to build : Build failed 解決 以下のように docker-compose.yml を修正する。 docker-compose.yml version: '3' services: app: build: context: . dockerfile: ./Dockerfile C:\dev\tutorial-docker>docker-compose up -d Building app [+] Building 0.4s (5/5) FINISHED ~ Creating tutorial-docker_app_1 ... done 正常にビルドされた。 参考 https://qiita.com/sam8helloworld/items/e7fffa9afc82aea68a7a
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker [基礎]

Dockerとは? ・簡単に開発環境を構築できるツール。 ・アプリの開発・デプロイが簡単になるツール。 OSによってWebアプリが動いたり動かなかったりするが、Dockerを使うことによって、OSごと1つのパッケージにまとめてくれるため、そのようなことは起きない。 開発環境、本番環境、問わず利用できる。 Dockerのダウンロード こちらからインストール可能。 赤枠のボタンをクリック。 Mac版、Windows版があるので自分のPCにあっている方をダウンロードする。 解凍してアプリケーションを開ける。 ターミナル(PowerShell)で docker --version と入力する。 Docker version xx.xx.x, build xxxxxxx 上記のようなコードが出てくる。 xの部分は個々人によって異なる。 Dockerの基本の仕組み 基本的な仕組みは上記の通り。 Q. Dockerデーモンとは? A. Dockerデーモンは Linux のデーモンプロセスで、Docker Engine API が呼び出されるのを待ち受けています。Dockerデーモンは、呼び出された Docker Engine API に応じて、イメージのビルドやコンテナの起動などを行います。 さわって理解する Docker 入門 より Dockerデーモンが命令を受け取ると、レジストリからイメージを取得。それを基にしてコンテナを作成する。 Dockerの基本操作 イメージ作成 docker image build -t sample/sample1:latest . docker image build このコマンドでimage(イメージ)をbuild(作成)している。 -t sample/sample1 このコマンドでタグを設定している。 雰囲気としては、以下の通り。 今回は、sampleという領域の中にsample1というファイルを作成した、ということになる。 1つのイメージから複数のコンテナを作成することもあるため、タグで名前を分けておいたほうが後々、楽に操作することが可能。 :latest 最新バージョンを指定している。 . 最後の.(ドット)は現在のディレクトリであると示している。 Dockerfileのあるディレクトリで操作しているときに使う。 コンテナ作成・起動 docker container run -d -p xxxx:xxxx --name test sample/sample1:latest xxxx/xxxxの中にはポート番号を設定する。 Dockerfileで設定したportの番号をそのまま入力する。 コンテナ停止 docker container stop test コンテナ削除 docker container rm test 感想 内容のほとんどは備忘録でしたが、「Dockerとはなんぞや」という人の役に立てればいいなと思います。 Dockerを使うに当たり[Dockerファイル]が必須になるのですが、それについてはまた書きます。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

dockerコンテナに複数のドメイン名でアクセスする(Docker for Windows)

Dockerコンテナにドメイン名でアクセスする場合jwilder/nginx-proxyを使うと簡単です。ここでは、1つのコンテナに複数のドメイン名でアクセスする方法を記載します。 docker-compose.yml services: proxy: image: jwilder/nginx-proxy ports: - "80:80" volumes: - /var/run/docker.sock:/tmp/docker.sock:ro app: build: context: .. dockerfile: ./docker/php/Dockerfile volumes: - ../app:/var/www/html - ./php/php.ini:/usr/local/etc/php/php.ini environment: - VIRTUAL_HOST=domain_1.local,domain_2.local,domain_3.local - VIRTUAL_PORT=8 環境変数のVIRTUAL_HOSTにカンマ区切りで書きます。 Multiple Hosts If you need to support multiple virtual hosts for a container, you can separate each entry with commas. For example, foo.bar.com,baz.bar.com,bar.com and each host will be setup the same. 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Docker+Laravel】よく使うコマンド集

Laravelのバージョン確認 php artisan --version or php artisan -V キャッシュ削除 applicationキャッシュクリア php artisan cache:clear routeキャッシュクリア php artisan route:clear configキャッシュクリア php artisan config:clear viewキャッシュクリア php artisan view:clear 定義されているルーティング一覧を確認 php artisan route:list デバッグ ファイルに出力して、デバッグや変数の内容を確認 logger()->debug($hoge); メソッド一覧 メソッド 内容 emergency システムが使用不可なレベル alert 緊急に対処すべきレベル critical 致命的なエラーレベル error 一般的なエラーレベル warning 警告レベル notice 通知レベル info システム情報レベル debug デバッグ情報レベル 作成中に変数の値を確認(web上で確認) dd($hoge);
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker Desktopを使わないDockerのインストール for Mac

Docker Desktopの代替方法 Docker Desktopが有料化ということで、Docker Desktopが使えない場合、代替方法についてのメモ。 Dockerの仕組み 普段使っているDocker=Docker Engineであり、Dockerデーモンによって構成されるクライアント・サーバーアプリケーションである。このDocker EngineはLinux上でしか対応していないので、MacやWindowsでは直接起動できない。そのためDoker Desktopで仮想環境を構築して、そこで起動している。 なので、仮想環境を用意すれば良いということ。 今回はVirtualBoxとDocker Machineを使って起動する。 前提 Docker Desktopがインストールされていない環境の前提です。 Docker DesktopをインストールするとDocker Engineとかも一緒にインストールされてしまっているので、この方法を実行するとうまくいかない可能性があります。 こちらの方法を実行する前にアンインストールすることを推奨します。 1. Homebrew Homebrew使ってインストールしていくので、以下を参照してインストール。 2. Dockerインストール HomebrewでDocker(Docker Engine)をインストールします。 caskのDockerはDocker Desktopなので注意。 以下のコマンドでインストール brew install docker 3. Docker Machineをインストール Docker Machineは仮想マシン上にDocker Engineをインストールするツール。 これを使ってVirtulboxにDockerをインストールします。 以下のコマンドでインストール brew install docker-machine 4. ViutualBoxのインストール 仮想マシンを起動するためにViutualBoxをインストールします。 以下からインストールしてください。 5. Docker Machineを使って仮想マシンを作成 準備ができたのでDocker Machineを使って仮想マシンを作成します。 まずは仮想マシンの一覧を見てみます。 仮想マシン一覧 docker-machine ls 結果 NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS 何も作成されていないのが確認できます。 仮想マシンの作成は以下のコマンドで作成します。 仮想マシンを作成 docker-machine create --driver virtualbox default default は仮想マシンの名前になります。 既に default が存在している場合は別の名前にします。 作成後にもう一度 ls してみます。 仮想マシン一覧 $ docker-machine ls NAME ACTIVE DRIVER STATE URL SWARM DOCKER ERRORS default - virtualbox Running tcp://192.168.99.100:2376 v19.03.12 作成が確認できました。 6. 環境変数を設定 Dockerコマンドでコンテナを構築する前に、Dockerの接続先等の環境変数をセットする必要があります。 以下のコマンド実行で一括設定できます。 環境変数を設定 eval "$(docker-machine env default)" docker-machine env default で必要な環境変数がエクスポートされるので上記で簡単にセットできます。 仮想マシンの再起動やシェルの再起動で毎回実行が必要になります。 毎回の設定が面倒な場合以下のように.zshrcとかに記載しても良いかもしれないですね。 毎回実行面倒な人用 echo 'eval "$(docker-machine env default)"' >> ~/.zshrc 7. コンテナを起動してみる これでおおよそ完了したのでコンテナを起動してみます。 docker pull swaggerapi/swagger-editor docker run -d -p 8080:8080 swaggerapi/swagger-editor swagger-editorを起動してみました。 確認してみましょう。 接続先は仮想マシンのIPを指定する必要があります。 以下のコマンドでわかります。 IPアドレスを確認 docker-machine ip default 結果 192.168.99.100 まあ、docker-machine ls で表示されたURLのIPアドレスとと同じになると思います。 http://192.168.99.100:8080 で接続すると確認できるかと思います。 8. localhostで接続したい いちいちIPアドレス覚えておくのも調べるのも面倒なので、localhostで繋ぎたいと思ったはず。 そんなときはVirtualBoxのポートフォアーディング使いましょう。 VirtualBoxを開くとdefaultマシンがあるのでそちらの設定を表示。 ”ネットワーク”の”アダプター1”で”高度”を開いて怪しいフォントの”ポートフォアーディング”を選択。 ここにポート設定を添付の画像のように記載。 今回はlocalhost(127.0.0.1)の8080ポートを仮想マシンの8080ポートに転送する。 これでOKをクリックすれば完了です。 http://localhost:8080 いざ接続してみましょう。 成功しました! 9. 仮想マシンの起動とか停止 しばらく使用しない場合や都度都度実行&停止したい時は以下を仮想マシンを停止します。 仮想マシンを停止したい場合は以下を実行します。 停止 docker-machine stop default 起動は以下。 起動 docker-machine start default おわり 上記でだいたいできるとは思っています。 まあ、Docker Desktop利用できる人はそのままDocker Desktop使った方が簡単であるし、Docker応援するためにお金は払った方が良い。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

MinIOの管理画面にアクセスすると別ポートにリダイレクトされる件の解消

下記のようにdocker-compose.ymlに記載して、DockerCompose環境でMinIOを使おうとしました。 docker-compose.yml minio: image: minio/minio ports: - "9000:9000" volumes: - ./.docker/minio/data:/export environment: MINIO_ACCESS_KEY: ${AWS_ACCESS_KEY_ID} MINIO_SECRET_KEY: ${AWS_SECRET_ACCESS_KEY} command: ['server', '/data'] http://localhost:9000にアクセスしても、なぜか別ポートにリダイレクトされてしまいました。 調査に時間がかかってしまい完全にハマっていたのですが、ふとdocker-compose upした時のログを見てみると、 WARNING: Console endpoint is listening on a dynamic port (35135), please use --console-address ":PORT" to choose a static port. リダイレクトしてしまうポート番号に一致する番号が書かれてる! こちらの記事が大変参考になったのですが、どうやらMinIOの仕様変更で、--console-addressオプションをつけて起動しないと、ポートが動的に設定されるようになったのだとか。 古い記事を見ながら手探りで構築していたのでハマってしまったようです。 下記のようにdocker-compose.ymlを書き換えることで解決しました。 docker-compose.yml minio: image: minio/minio ports: - "9000:9000" - "9001:9001" volumes: - ./.docker/minio/data:/export environment: MINIO_ACCESS_KEY: ${AWS_ACCESS_KEY_ID} MINIO_SECRET_KEY: ${AWS_SECRET_ACCESS_KEY} command: ['server', '/data', '--console-address', ':9001'] 普段docker-compose up -dしていたせいで、ログが見つけづらい状況で開発していたのも調査に時間がかかった原因です。 普段からログ出しとく癖は必要ですね、という学びを得ました。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

IBM Cloud Container Registryにイメージを登録するいくつかの方法

目的 IBM Cloud Container Registry(ICR)はIBM Cloudが提供するコンテナレジストリサービスです。ICRにイメージを登録する方法はいくつかありますが、最近IBM Cloud CLIを使った方法が非推奨になってしまったので、代替策も含めて紹介します。 サンプルアプリ 当手順で使用するソースコードやDockerfileはGitHubで公開していますので、参考にしてください。 方法 IBM Cloud Container Registry CLIを使用する(現在非推奨) IBM Cloud Container Registry CLIはもともとイメージをビルドし登録する機能がありました。これを使うとローカルにdockerやpodmanをインストールしておく必要がなく楽でした。しかし残念ながら2021年9月からこの方式は非推奨となり、今後廃止されることになりました。現時点(2021年9月)では--accept-deprecationオプションを付与しないと動かなくなっています。 $ git pull $ ibmcloud region-set jp.icr.io $ ibmcloud cr build -t jp.icr.io/teruq/sample-app:1.0.0 . 失敗 The 'build' command is deprecated, you must specify the --accept-deprecation option to use this command. For more information see: https://www.ibm.com/cloud/blog/announcements/ibm-cloud-container-registry-deprecating-container-builds $ ibmcloud cr build -t jp.icr.io/teruq/sample-app:1.0.0 --accept-deprecation . 警告: build コマンドは推奨されません。 詳しくは、次のページを参照してください: https://www.ibm.com/cloud/blog/announcements/ibm-cloud-container-registry-deprecating-container-builds Sending build context to Docker daemon 194.7MB (略) OK DockerやPodmanを使用する DockerやPodmanを使用する方法です。ibmcloud cr loginを実行することでdockerやpodmanコマンドからICRを利用できるようになります。しかしこのためにそれぞれのツールをローカルにインストールする必要があります。 $ git pull $ ibmcloud cr region-set jp.icr.io $ ibmcloud cr login $ docker build -t jp.icr.io/teruq/sample-app:1.0.0 . $ docker push jp.icr.io/teruq/sample-app:1.0.0 IBM Cloud Code Engineのビルド機能を使用する 少々変則的な使い方ですが、IBM Cloud Code Engineのビルド機能を使うことで、ICRへのイメージ登録を行うことができます。DockerやPodmanは不要です。また、Dockerfileやソースコードをあらかじめローカルにpullする必要がないところも楽です。 プロジェクトの作成 Code Engineのプロジェクトを作成します。ビルドの種類ごとに分ける必要はないので1つあればよいでしょう。 $ ibmcloud ce project create --name image-build プロジェクト 'image-build' を作成中... プロジェクト「image-build」の ID は「72ed867c-5480-4c6c-b840-801fcf4bd419」です。 プロジェクト 'image-build' がアクティブになるのを待機しています... プロジェクト 'image-build' の選択中。 OK アクセスシークレットの登録 ICRにアクセスするためのシークレットを登録します。これも1つあればよいでしょう。--passwordはICRに更新権限のあるAPIキーです。 $ ibmcloud ce registry create --name jp-icr-io-teruq --password ******** --server jp.icr.io イメージ・レジストリーのアクセス・シークレット 'jp-icr-io-teruq' を作成中... OK ビルドの作成 $ ibmcloud ce build create --name sample-app --image jp.icr.io/teruq/sample-app:1.0.0 --registry-secret jp-icr-io-teruq --source https://github.com/teruq-sample/sample-app.git --commit master --size small ビルド 'sample-app' を作成中... OK ビルドの実行 $ ibmcloud ce buildrun submit --build sample-app --wait ビルド実行 'sample-app-run-210917-013517853'を送信中... ビルド実行が完了するのを待機しています... ビルド実行状況: '実行中' ビルド実行が正常に完了しました。 ビルド実行の状況を確認するには、'ibmcloud ce buildrun get -n sample-app-run-210917-013517853' を実行してください。 OK ビルドログの確認 $ ibmcloud ce buildrun logs --buildrun sample-app-run-210917-013517853 (略) #13 exporting to image #13 pushing layers 2.8s done #13 pushing manifest for jp.icr.io/teruq/sample-app:1.0.0@sha256:94ec1c570ac434dced550cba328229b57d5123fb83048d124a1df31497e97c3f #13 pushing manifest for jp.icr.io/teruq/sample-app:1.0.0@sha256:94ec1c570ac434dced550cba328229b57d5123fb83048d124a1df31497e97c3f 0.4s done #13 DONE 8.6s Red Hat OpenShift on IBM CloudのBuildを使用する これも少々変則的ですが、Red Hat OpenShift on IBM Cloud(ROKS)のユーザーであれば、ROKSのBuildを使ってICRにイメージ登録することができます。 レジストリシークレットの登録 ICRにイメージをプッシュ可能なシークレットを作成します。--docker-passwordはICRに更新権限のあるAPIキーです。 $ oc create secret docker-registry jp-icr-io-teruq --docker-server jp.icr.io --docker-username iamapikey --docker-password ******** --docker-email a@b.c secret/jp-icr-io-teruq created サービスアカウントにレジストリシークレットをリンク BuildConfigによるBuildコンテナがICRにイメージをプッシュできるよう、サービスアカウントにレジストリシークレットをリンクします。 $ oc secrets link builder jp-icr-io-teruq ビルドの実行 BuildCondigを作成して実行します。--to-dockerを指定することで生成されたイメージを外部のレジストリに登録することを指定し、--toでICRを指定します。 $ oc new-build https://github.com/teruq-sample/sample-app.git --to-docker --to jp.icr.io/teruq/sample-app:1.0.0 --> Found image d0a3436 (2 months old) in image stream "default/open-liberty" under tag "21.0.0.7-full-java8-openj9" for "open-liberty:21.0.0.7-full-java8-openj9" * A Docker build using source code from https://github.com/teruq-sample/sample-app.git will be created * The resulting image will be pushed with Docker to "jp.icr.io/teruq/sample-app:1.0.0" * Use 'oc start-build' to trigger a new build --> Creating resources with label build=sample-app ... buildconfig.build.openshift.io "sample-app" created --> Success ビルドログの確認 ビルドログを確認します。 $ oc get pods NAME READY STATUS RESTARTS AGE sample-app-1-build 1/1 Running 0 3s $ oc logs -f sample-app-1-build Pushing image jp.icr.io/teruq/sample-app:1.0.0 ... Getting image source signatures Copying blob sha256:3f0cfe4ac5fafbc38dd1ca8759c632b0dc2b7ad895a75900a6734b695d6b4097 (略) Copying config sha256:3d40901987e5747876bd832628ea6dc4b7a6c28d47baad89ee221bf159f3f9cd Writing manifest to image destination Storing signatures Successfully pushed jp.icr.io/teruq/sample-app@sha256:800ec73d5084ca3f485ee3c74c25632b21e9d78387f5d8bfe1f9bc87790f54f5 Push successful IBM Cloud ToolChainサービスを使用する IBM CloudのCI/CD機能を使ってICRへイメージ登録することができます。 ツールチェーンの作成 下記URLから、Build your ownツールチェーンを選択します。 https://cloud.ibm.com/devops/create 名前をつけて作成します。 ツールの追加を選択します。 IBM CloudのGitLabを使用する場合は左を、github.comを使用する場合は右を選択します。今回は右のGitHubを使用します。 初回の場合、GitHubの認証を行います。 Authorize IBM-Cloudを選択します。 リポジトリータイプを既存にし、リポジトリーURLを指定します。統合の作成を選択します。 再度ツールの追加を選択します。 Delivery Pipelineを選択します。 名前を付けて作成します。 Delivery Pipelineを選択します。 ステージの追加を選択します。 入力タイプ、リポジトリー、ブランチを選択します。ステージトリガーは今回は手動にします。 ジョブタブを選択し、ビルドジョブを追加します。 ビルダータイプをContainer Registryにします。 名前空間、イメージ名を指定します。 ビルドスクリプトを2か所書き換えます。デフォルトだとイメージのタグがBUILD_NUMBERという連番になりますが、今回はバージョンを明示したいためです。 #!/bin/bash echo -e "ビルド環境変数:" echo "REGISTRY_URL=${REGISTRY_URL}" echo "REGISTRY_NAMESPACE=${REGISTRY_NAMESPACE}" echo "IMAGE_NAME=${IMAGE_NAME}" echo "BUILD_NUMBER=${BUILD_NUMBER}" echo "IMAGE_TAG=${IMAGE_TAG}" # 追加 # 環境変数についての詳細:: # https://cloud.ibm.com/docs/services/ContinuousDelivery?topic=ContinuousDelivery-deliverypipeline_environment#deliverypipeline_environment # ビルド・オプションを確認または変更するには、次の項目を使用します:: echo -e "リポジトリー・ルートで Dockerfile を検査しています" if [ -f Dockerfile ]; then echo "Dockerfile が見つかりました" else echo "Dockerfile が見つかりません" exit 1 fi #ensure docker and buildkit are present if not already in current pipeline-base-image which buildctl > /dev/null || (curl -fsSL https://github.com/moby/buildkit/releases/download/v0.8.0/buildkit-v0.8.0.linux-amd64.tar.gz | tar zxf - --strip-components=1 -C /usr/bin bin/buildctl) which docker > /dev/null || (curl -fsSL https://download.docker.com/linux/static/stable/x86_64/docker-19.03.9.tgz | tar zxf - --strip-components=1 -C /usr/bin docker/docker) FULL_IMAGE_NAME=$REGISTRY_URL/$REGISTRY_NAMESPACE/$IMAGE_NAME #Classic pipeline Container Registry job requires PIPELINE_IMAGE_URL to be defined, so the next deploy job could access this value: #export PIPELINE_IMAGE_URL="${FULL_IMAGE_NAME}:$BUILD_NUMBER" export PIPELINE_IMAGE_URL="${FULL_IMAGE_NAME}:${IMAGE_TAG}" # BUILD_NUMBERからIMAGE_TAGに変更 echo -e "コンテナー・イメージをビルドしています" set -x ibmcloud cr login buildctl build --frontend dockerfile.v0 --local context=. --local dockerfile=. \ --output type=image,name=${PIPELINE_IMAGE_URL},push=true \ --export-cache type=registry,ref=${FULL_IMAGE_NAME}:buildcache \ --import-cache type=registry,ref=${FULL_IMAGE_NAME}:buildcache set +x 環境プロパティタブを選択します。 IMAGE_TAGプロパティを追加します。最後に保存します。 ビルドの実行 ▶ボタンを選択するとビルドが開始されます。 状況はログおよび履歴の表示で確認することができます。 比較 方法 Docker/Podmanが必要 ソースの置き場所 IBM Cloud Container Registry CLI No ローカル Docker/Podman Yes ローカル IBM Cloud Code Engineのビルド機能 No Gitのみ Red Hat OpenShift on IBM CloudのBuild No ローカルとGitどちらも可能 IBM Cloud ToolChainを使用 No Gitのみ
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Docker上のUbuntu 20.04 にSMTPクライアントのmsmtpを導入して、GmailのSMTPサーバを使ったメール送信の動作確認をする

用意した物 Docker for WindowsのセットアップされたPC(例えば、https://qiita.com/fkooo/items/d2fddef9091b906675ca を参照。) Windows 10 Pro 64bit AMD Ryzen 7 3700X@2.20GHz 32GB Memory Gmailアカウント 前準備 GmailのSMTPサーバをmsmtpから利用するには、サードパーティアプリケーションによるアクセスを有効にする必要があります。 以下のURLから、Googleアカウントでログインし、「安全性の低いアプリのアクセス」欄の「安全性の低いアプリの許可」を「有効」にします。 https://www.google.com/settings/u/2/security/lesssecureapps 次に、PowerShellかコマンドプロンプトで、Ubuntu 20.04のイメージを落としてきて、動作確認のため終了後にコンテナを自動削除するようにrmオプションで起動します。 docker run --rm -it ubuntu:bionic bash 起動後はrootアカウントでログインした状態になっています。そのまま、システムアップデートしておきます。 apt update && apt dist-upgrade -y msmtpの導入と動作確認 まずは、msmtpをaptで導入します。 apt install -y msmtp msmtp-mta 次に、msmtpの設定ファイルを作成します。 echo -e "\ defaults\n\ syslog LOG_MAIL\n\ aliases /etc/aliases\n\ tls on\n\ tls_starttls on\n\ tls_certcheck off\n\ auth on\n\ account gmail\n\ host smtp.gmail.com\n\ port 587\n\ from [アカウント名]@gmail.com\n\ user [アカウント名]@gmail.com\n\ password [パスワード]\n\ account default : gmail\n\ " | sudo tee -a /etc/msmtprc パスワードに記号が含まれる場合には、エスケープする必要があります。 そして、テストメールを送付します。 echo 'hello world' | msmtp -v [アカウント名]@gmail.com エラーなく送信できれば成功です。 設定ファイル内にパスワードが平文で書かれたままであるのは、セキュリティ的に良くありません。 そこで、GnuPGでパスワードを暗号化したファイルを作成しておいて、利用時に読み込んで復号化するようにします。 GnuPGの導入と動作確認 GnuPGをaptで導入します。 apt install gnupg まずは、プライマリキーを作成します。 gpg --expert --full-gen-key ここでは対話的に、以下のようにして作成しました。 gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. gpg: directory '/root/.gnupg' created gpg: keybox '/root/.gnupg/pubring.kbx' created Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key Your selection? 11 Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? s Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate Current allowed actions: Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? q Please select which elliptic curve you want: (1) Curve 25519 (3) NIST P-256 (4) NIST P-384 (5) NIST P-521 (6) Brainpool P-256 (7) Brainpool P-384 (8) Brainpool P-512 (9) secp256k1 Your selection? 1 Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: [フルネーム] Email address: [アカウント名]@gmail.com Comment: You selected this USER-ID: "[フルネーム] <[アカウント名]@gmail.com>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: /root/.gnupg/trustdb.gpg: trustdb created gpg: key E2DE895741D650C5 marked as ultimately trusted gpg: directory '/root/.gnupg/openpgp-revocs.d' created gpg: revocation certificate stored as '/root/.gnupg/openpgp-revocs.d/5E28E1E64EA825B98BFCD07AE2DE895741D650C5.rev' public and secret key created and signed. pub ed25519 2021-09-16 [C] 5E28E1E64EA825B98BFCD07AE2DE895741D650C5 uid [フルネーム] <[アカウント名]@gmail.com> 無事に作成できているかどうかを、確認しておきます。 gpg --list-keys gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u /root/.gnupg/pubring.kbx ------------------------ pub ed25519 2021-09-16 [C] 5E28E1E64EA825B98BFCD07AE2DE895741D650C5 uid [ultimate] [フルネーム] <[アカウント名]@gmail.com> 次に、暗号化機能を持つサブキーを作成します。 gpg --expert --edit-key 5E28E1E64EA825B98BFCD07AE2DE895741D650C5 ここでは、対話的に以下のように作成しました。 gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec ed25519/E2DE895741D650C5 created: 2021-09-16 expires: never usage: C trust: ultimate validity: ultimate [ultimate] (1). [フルネーム] <[アカウント名]@gmail.com> gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 12 Please select which elliptic curve you want: (1) Curve 25519 (3) NIST P-256 (4) NIST P-384 (5) NIST P-521 (6) Brainpool P-256 (7) Brainpool P-384 (8) Brainpool P-512 (9) secp256k1 Your selection? 1 Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec ed25519/E2DE895741D650C5 created: 2021-09-16 expires: never usage: C trust: ultimate validity: ultimate ssb cv25519/E2BC99E6A0CE6B17 created: 2021-09-16 expires: never usage: E [ultimate] (1). [フルネーム] <[アカウント名]@gmail.com> gpg> q Save changes? (y/N) y 作成が終わったら、再び確認します。 gpg --list-keys サブキーを示す"sub"と暗号化機能を示す"[E]"を持つ行が、リストに追加されていれば成功です。 /root/.gnupg/pubring.kbx ------------------------ pub ed25519 2021-09-16 [C] 5E28E1E64EA825B98BFCD07AE2DE895741D650C5 uid [ultimate] [フルネーム] <[アカウント名]@gmail.com> sub cv25519 2021-09-16 [E] 作成したキーを使って、パスワードを暗号化して保存します。 gpg --encrypt -o /root/.msmtp-gmail.gpg -r [アカウント名]@gmail.com - キーボードからパスワードを入力し、Enterキーを押してからCtrl+dキーの押下で終了します。 暗号化されたパスワードが書き込まれた/root/msmtp-gmail.gpgというバイナリファイルが、作成されます。 この暗号化パスワードファイルを読み込むように、msmtpの設定ファイルを作成し直します。 rm /etc/msmtprc echo -e "\ defaults\n\ syslog LOG_MAIL\n\ aliases /etc/aliases\n\ tls on\n\ tls_starttls on\n\ tls_certcheck off\n\ auth on\n\ account gmail\n\ host smtp.gmail.com\n\ port 587\n\ from [アカウント名]@gmail.com\n\ user [アカウント名]@gmail.com\n\ passwordeval \"gpg --quiet --for-your-eyes-only --no-tty --decrypt /root/.msmtp-gmail.gpg\"\n\ account default : gmail\n\ " | sudo tee -a /etc/msmtprc テストメールを送付します。 echo 'hello world' | msmtp -v [アカウント名]@gmail.com エラーなく送信できれば成功です。 おわりに 以上で、動作確認が終わりました。コマンドラインから抜けます。 exit Docker上のUbuntu 20.04のコンテナは、自動的に削除されます。 参考サイト
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

2.1.Docker / docker-compose インストール・初期設定

概略 なぜDockerを使うのか 皆さんは開発環境はWindows・検証/本番環境がLinuxのため、単体テスト自動化を行った場合開発環境ではうまくいったのに検証環境では動かないという経験はないでしょうか?環境差異があることによる開発の難しさです。 それらの諸問題解消するためには現時点ではDockerを使用するのが一番手っ取り早いでしょう DockerをWindows開発環境で利用し、ほぼ本番環境と同じ環境を構築することにより、環境差異をなくし、テストを容易にします。 Dockerとは アプリケーションサービスを1つの仮想環境として実行するアプリケーションです。基本的には1環境1サービスとして「Dockerイメージ」を作成します。そして、下図のようにイメージをサービスとして1つ、または、複数起動します。起動したサービスを「Dockerコンテナ」といいます。 細かい技術については説明を省きますがLinuxの仮想環境として同じ技術を使用した「LXD」(LXCの後継アプリケーション)がありますが、こちらはサービスを実行するOSを仮想環境として起動します。 Dockerの利点として下記の点が挙げられます。 Docker仮想環境はコンテナ型と呼ばれるもので、Linuxカーネルに直接アクセスするためオーバーヘッドが少ない。 各アプリケーションの公式がDockerHubと呼ばれるリポジトリサイトにDockerイメージを提供しているためサービスを利用しやすい。 環境のバージョンや詳細な設定はDockerfileやdocker-compose.yml等のファイルに記載している(環境のコード化:Infrastructure as Code)ためバージョンアップやサービス環境のリリース・配布が容易。 Dockerイメージさえ作成できていればDockerコンテナを起動するのは数秒もかからない。必要なサービスを必要な時に起動できるためメモリやCPUの消費が少ない。 docker-composeとは Dockerは1つのサービス仮想環境を実行するためのアプリケーションでDockerfileは1つのDockerイメージをビルドするための設定ファイルですが、通常Webアプリケーション等は複数のDockerfileで定義されたDockerイメージを同時に起動してシステムを構築する必要があります。 そういった場合、docker-composeで複数のDockerコンテナの起動をサポートします。 上図にあるようなシステムを構築する場合、RDB、AP、Webコンテナの順に起動したり、各コンテナの永続化データ(コンテナが停止してもコンテナ内のデータを残す)の設定を行います。 インフラの構築と言えばプログラミングとは全く別の世界を想像するかもしれませんが、Dockerはプログラミングができる人ならばマスターするのも容易かと思います。失敗しても環境の作り直しが可能ですのでとにかく使ってみましょう。 Docker関連アプリケーションのインストールと設定 1.Docker (Community Edition) インストール 下記のコマンドをWSL端末で実行します。 Dockerインストール $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable" $ sudo apt update && sudo apt upgrade -y && sudo apt install -y docker-ce 2.Dockerコマンドの権限設定 デフォルトユーザ(develop)でdocker daemonを操作可能にします。 下記のコマンドをWSL端末で実行します。 dockerユーザ設定 $ sudo groupadd docker $ sudo usermod -aG docker $USER 3.docker-composeインストール docker-composeの最新リリースのバージョンをリンク先のサイトで確認します。 下記のコマンドをWSL端末で実行します。 docker-composeインストール $ sudo curl -L "https://github.com/docker/compose/releases/download/<「1.」で調べたバージョン番号>/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose 4.docker-composeコマンドの権限設定 下記のコマンドをWSL端末で実行します。 docker-composeコマンド権限設定 $ sudo chmod +x /usr/local/bin/docker-compose 5.インストールバージョンの確認 下記のコマンドをWSL端末で実行します。 バージョン確認 $ docker --version 例) Docker version 20.10.8, build 3967b7d $ docker-compose --version 例) docker-compose version 1.29.2, build 5becea4c 2.Docker in WSL環境構築 < 前 2.1.Docker / docker-compose インストール・初期設定 次 > 2.2.Docker環境構成検討
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む