exec /usr/local/bin/docker-entrypoint.sh: exec format errorにハマる AWS ECRへプッシュ後、AWR ECSから起動しようとするとどうしてもコケる。 原因 イメージ作成時に稼働プラットフォームを指定すべきであった。

$ docker run -d --rm -e MYSQL_ROOT_PASSWORD=password mysql:8.0 Unable to find image 'mysql:8.0' locally 8.0: Pulling from library/mysql docker: no matching manifest for linux/arm64/v8 in the manifest list entries. この記事はM1MacでDockerを使ってMySQLのコンテナを立ち上げるためのものです。 事前準備 Docker Desktop(Preview)をインストール済 理由 M1Macのプラットフォームはarm64。 mysqlイメージのサポートプラットフォームはamd64。 イメージをプルする際に実行環境のプラットフォームに合わせて自動的にamd64のイメージを取得し、
ローカルの開発環境で動いているはずのMySQLにmysqlコマンドで接続しようとして、 Can't connect to local MySQL server through socket と言われたとき。 $ mysql -u root -p -h localhost -P 13306 DBNAME Enter password: ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) MySQLが動いてなかったり、あるはずのソケットファイルがなんらかの理由で見つからない場合にこのエラーになります。 Dockerコンテナで動かしているMySQLにホスト側からmysqlコマンドで接続しようとしている場合にもこのエラーになることがあります。
AWS Fargateを利用することが最近多く、コンテナ間の名前解決にはECS Service Discoveryをよく利用しています。ECS Service Discoveryは平たく言えばRoute53を利用してコンテナ間の名前解決できる仕組みです。 ふと手元に見るとローカルでコンテナ起動しているときはコンテナ間の名前解決をどこで行っているのか?を今まで気にしたことがありませんでした。気にしたことがなかったことに気づけたことは幸いです。手を動かして確認してみましょう。 まとめ Dockerはコンテナ間名前解決に利用できるService Discovery機能がある コンテナが指定するDNSサーバはループバック用のアドレス範囲にある127.0.0.11 ユーザ定義のネットワークを使用している場合に限り利用できる機能 デフォルトのネットワーク(bridge)はService Discove
はじめに これまでWSL2ではDocker を立ち上げるにはSystemdではなくserviceで立ち上げるのが定番でした。これはUbuntu 22.04以前ではSystemdがPID=1で立ち上がらいのが原因でDockerが立ち上がりませんでした。Ubuntu 22.04からはSystemdをPID=1で立ち上げる方法が確立したのでSystemdでDockerを利用できます。 そこでUbuntu 22.04を利用してSystemdでDockerを起動させる方法を紹介していきます。 --2022/09/30 追記-- Windows のビルドのバージョンは22000.0以上の場合、Windows 11 やWindows 10 Insider ProgramなどではWSLがSystemdに対応したのでこちらをお試しください。
Docker が少し前から「マルチステージビルド」なる機能を提供していましたが、ちょっとだけ使い込んでみる機会があったので、自分なりにまとめてみました。 TL;DR 1つの Dockerfile に何個も FROM が書ける 1つの FROM から次の FROM or ファイル末尾までが1ステージ COPY --from=foo で、既出のステージや出来合いのイメージからファイルをつまみ食いできる RUN の成果物だけあればよいようなケースに最適 (コンパイル言語系のシステムとか) FROM の元ネタとして、既存イメージの他に既出のステージも指定できる 多様だが共通部が多いようなイメージを作るケースで DRY にできる COPY --from=foo で、既出ステージの成果物つまみ食い COPY --from=foo の例 次は、 jemalloc をビルドするだけの一時的なイメージを作る
Railsなどサーバーサイド開発でDockerを使っているなら、docker-composeを使っている人は多いだろう。docker-compose.ymlでRails環境とDB環境(これらをサービスと読ぶ)を定義し、docker-compose upで、2つのコンテナを起動するのはよくあることだ。 よくあるケースなのでググればすぐ出てくるし、Dockerのネットワーク構成についてあまり理解してなくても問題なかったりする。しかし、Railsから別コンテナのSFTPサーバーにファイルをアップロードしたいとかになると、ググってもあまり出てこず、Dockerのネットワークについて理解しておかないとハマるかもしれない。 docker-compose.ymlで宣言したサービスは、docker-compose upなどでコンテナ起動すると、同一のネットワークに所属することになる(Dockerネットワー
Dockerコンテナの自動起動設定するオプション名と設定方法を紹介していきます。 概要Dockerには、再起動ポリシーという「コンテナ終了時に再起動するための仕組み」があります。 再起動ポリシーを設定しておけば、Dockerデーモンの起動時やホストOSの起動時に自動的にコンテナを開始することができます。 docker-composeを利用している場合の自動起動自動起動を有効化するには、以下のオプションを使います。 version: '2' services: wordpress: image: wordpress:latest ports: - "3001:80" environment: WORDPRESS_DB_NAME: wordpress WORDPRESS_DB_USER: mysql_user WORDPRESS_DB_PASSWORD: mysql_pw # 自動起動の有効化
Docker は使用していないオブジェクト、たとえばイメージ、コンテナ、ボリューム、ネットワークに対するクリーンアップには、慎重なアプローチをとっています。すなわち、各オブジェクトは Docker に対して明示的に削除を命令しない限り、削除されることはありません。その結果、Docker は巨大なディスク容量を使う事になりました。オブジェクトのタイプごとに、 Docker は prune (削除)コマンドを提供しています。さらに、 docker system prune を使えば、複数のオブジェクト・タイプを一度にクリーンアップできます。このトピックは各 prune コマンドをどのようにして使うか紹介します。
開発環境で使える Rails の Docker 環境構築です。 Docker とは関係ない話しも混じってます。 コンテナ構成 シンプルに Ruby をベースに Rails 環境をビルドします。 DB は PostgreSQL を使います。永続化に Volume を利用します。 Ruby Rails PostgreSQL ディレクトリ構成 RAILS_ROOT 配下の構成です (一部抜粋)。 RAILS_ROOT ├── .dockerignore ├── .env ├── .gitignore ├── Dockerfile ├── Gemfile ... ├── Makefile ├── README.md ... ├── config/ │ ... │ ├── database.yml ... ├── docker-compose.yml ...
すごいタイミングですごい本が出たもんだ。 本日はKubernetes Advent Calendar 2020 その1 向けのエントリー。 本当はCF for k8sの記事を書くつもりだったのだけど、先週盛り上がりまくったDockershimのDeprecated話の後ですごーく良い本が出てきたので、これは紹介せねばということで急遽内容を変更。 jaco.udcp.info CF for k8sの話も途中まで書いちゃっているのでまた日を改めて公開する。 あの神資料が本になったよ ということで今日の話題はこちら。 イラストでわかるDockerとKubernetes Software Design plus 作者:徳永 航平発売日: 2020/12/05メディア: Kindle版 今ではDockerやKubernetesに関する本もだいぶ出揃い、使い方を学ぶのには困らなくなってきた。それに、基
背景 docker-composeを利用するときに、コンテナ・ホスト名・データボリューム・ネットワーク名などの名前を指定しないと、自動的に名前が生成される。 あくまでも個人的な見解だが、ルールを覚えない限りは以下のような面倒な点があると考える。 作成されたものの名前を確認する必要がある。 意図せずにデフォルトネットワークが作られる。 コンテナ間通信するときのFQDNはコンテナ名がわからない。(これについては別ページで別途記載するが、サービス名でも通信できた) 自動生成されたデータボリュームがわからないので紐づけを確認する必要がある。 コンテナとデータボリュームの関係を確認するには以下の方法があるが、どちらもコマンド自体覚えるのが面倒。(他にもあるかもしれないし、alias作れと言われればその通りだが、ある程度覚えておかないと新しい環境で再度aliasの設定内容を調べないといけない) doc
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く