2021-10-24

AWS Copilot で Dockerfile をデプロイしてみた

aws_copilot.md

乱雑な作業記録です。

はじめに

いま、私の手元には Dockerfile があります。

動作確認が終わりました。

このままデプロイしたいです。

します。

ディレクトリ構成 (必要な部分のみ)

$ tree -a . ├── README.md ├── api │   └── Dockerfile └── docker-compose.yml

準備

これによると、AWS Copilot CLI と AWS CLI と Docker が必要らしいです。

基本的には AWS Copilot CLI だけで済みそうですね。

$ brew install aws/tap/copilot-cli

あと、こちらが AWS Copilot CLI 公式ドキュメント です。

AWS Copilot のコンセプトを少し理解する

こちら を読むと、AWS Copilot は以下のような構成をしているようです。

  • Application : 以下の 2 個を包括する概念

    • Environment : いわゆるデプロイステージ ( dev, stg, prod など )

    • Service : 他の AWS サービス ( DynamoDB, S3 など )

したがって、この順番に作成していこうと思います。

Application を作成する

まずは Application を作成します。名前はプロジェクト名と同名にしました。

$ copilot app init ${アプリケーション名}

なお、このときに Route 53 に登録済みの既存ドメイン名を利用することができ、これなら HTTPS が使えるようです。(まだ試していません)

$ copilot app init ${アプリケーション名} --domain example.com

少し待つと、copilot ディレクトリが作成されました。

$ tree -a . ├── README.md ├── api │   └── Dockerfile ├── copilot │   └── .workspace └── docker-compose.yml

Environment を作成する

次に dev という名前の Environment を作成します。

$ copilot env init \ --name "dev" \ --profile "default" \ --default-config

上記の --profile ではどの AWS Credentials を使用するかを指定しているので、使用したいプロファイル名を指定してください。

なお、パラメーターなしで copilot env init を実行すれば、対話でいろいろ聞いてくれます。

これで AWS 上に色々必要なリソースが作成されるようです。

作成されたリソースのプレフィックスは、だいたい {App}-{Env}- でした。

Service を作成する

次に app という名前の Service を作成します。

$ copilot svc init \ --svc-type "Load Balanced Web Service" \ --name "app" \ --dockerfile "./api/Dockerfile" \ --port "80"

なお、パラメーターなしで copilot svc init を実行すれば、対話でいろいろ聞いてくれます。

少し待つと、copilot ディレクトリの下に app/manifest.yml が作成されました。

$ tree -a . ├── README.md ├── api │   └── Dockerfile ├── copilot │   ├── .workspace │   └── app │   └── manifest.yml └── docker-compose.yml

ちなみに、ポート番号に 80 以外を設定していると、うまくいきませんでした。

よく調べていないので原因不明ですが、そのうちちゃんと調べようと思います。

その他の AWS サービスを作成する

他に必要な AWS サービスがある場合、まずは copilot storage init をしてみてください。

すると、DynamoDB・S3・Aurora のいずれかのリソースを作成するための対話が始まります。

この時点では AWS リソースは作成されないので、適当に db という名前で作成してみます。

すると、copilot/app ディレクトリの下に addons/db.yml が作成されました。

$ tree -a . ├── README.md ├── api │   └── Dockerfile ├── copilot │   ├── .workspace │   └── app │   ├── addons │   │   └── db.yml │   └── manifest.yml └── docker-compose.yml

この YAML ファイルは AWS CloudFormation の記法で書かれており、公式ドキュメントの ここ を参考にして、欲しい AWS リソースを定義すれば良さそうです。

私は、Aurora (PostgreSQL) と Cognito User Pool を作成しました。

デプロイする

最後に、デプロイします。

Environment は dev で、Service は app です。

$ copilot svc deploy \ --env "dev" \ --name "app"

初回のデプロイは、かなり時間が掛かると思います。

また、次回以降のデプロイも同じコマンドでできますが、リソースに変更がないと判断されるとデプロイしてくれません。

そのときは、--force のオプションをつけるとデプロイできます。

追加の AWS リソースでエラーが発生したら

追加の AWS リソースのデプロイでエラーが発生すると、CloudFormation のいつもの悪癖で、ロクに理由を教えてくれません。

と思ったのですが、自分の探し方が悪かったようで、スタックが別に分けてありました。

メインのスタック名が {App}-{Env}-{Service} の形式ですが、追加の AWS リソースは {App}-{Env}-{Service}-AddonsStack-XXXXXXXXXXXX というスタック名です。

そこのイベントに、エラーの詳細が多少は書かれています。

メモ

似たようなことができるヤツで、Docker Compose for Amazon ECS というものがありました。

今回はうまくいかなかったので断念しましたが、選択肢の一つとして頭の片隅に留めておきたいと思いました。

どうせ忘れるのでメモしときました。

2021-10-07

Error: pg_config executable not found.

pg_config_executable_not_found.md

概要

Python で psycopg2 をインストールしようとしたとき、以下のようなエラーが発生することがありました。

Error: pg_config executable not found.

解決方法としては、以下を試してみてください。

  1. PostgreSQL をインストールする
  2. OpenSSL をインストールする
  3. 環境変数 LDFLAGS, CPPFLAGS を設定する

Psycopg 2 とは

Python 向けの PostgreSQL データベースアダプターらしいです。

自分はこれを知らなかったので、PostgreSQL をインストールしていないのに Psycopg 2 をインストールしようとして、エラーを吐いていました。

エラーを解消する

あとは粛々と進めるだけですが、メモは残しておきます。

$ brew install postgresql $ brew install openssl

OpenSSL をインストールすると、環境変数を設定するコマンドが表示されたと思うので、環境変数 LDFLAGS, CPPFLAGS を設定すれば大丈夫だと思います。

恐らくこんなやつですが、コマンドが表示されていたらそっちを使った方が良いでしょう。

$ export LDFLAGS="-L/usr/local/opt/openssl/lib" $ export CPPFLAGS="-I/usr/local/opt/openssl/include"

2021-10-06

E: Unable to locate package XXXXX

unable_to_locate_package_xxxxx.md

概要

Linux でパッケージを apt-get install するとき、以下のようなエラーが発生することがありました。

E: Unable to locate package XXXXX

解決方法としては、以下を試してみてください。

  1. apt update or apt-get update してから再試行する
  2. パッケージが存在するかを確認する

このうち、1. は検索するといっぱい出てくるので割愛します。そもそも説明するほどでもなく、実行するだけです。

一方、2. については一言で書くと元も子もないのですが、ここにたどり着くのが結構大変だったので、メモを残しておきます。

前提状況

Docker Compose でビルドしようとしたとき、以下のような Dockerfile で、以前はビルドできていたものが、本題のエラーを吐いていました。

FROM tiangolo/uvicorn-gunicorn-fastapi:python3.8 RUN apt-get update && \ apt-get install -y --no-install-recommends postgresql-client-11

ちなみに、このエラーは postgresql-client-13 にすることで解決しました。いつの間にか 11 が使用できなくなっていたようです。

使用する PostgreSQL の Docker イメージも、バージョンを合わせて postgres:13.4-alpine にしました。

Linux のバージョンやコードネームを確認する

まず、以下のようなコマンドで、使用している Linux のバージョンやコードネームを確認します。

$ cat /etc/lsb-release # Ubuntu $ cat /etc/os-release # Debian

自分の場合、どのディストリビューションか分からなかったので、以下のようにして確認しました。

  • Dockerfile のエラーを吐いた行を含めてコメントアウトして、できるだけ小さい構成でビルドして起動する
  • Docker コンテナに入って、「Linux バージョン 確認」で検索して出てきたコードを片っ端から実行する

ちなみに、Debian GNU/Linux 11 (bullseye) でした。

ディストリビューションのパッケージを検索する

使用している Linux のディストリビューションの公式ページで、パッケージ検索ページを開きます。

その他のディストリビューションでも「Debian パッケージ」みたいに検索すると、出てくると思います。

あとは、インストールに失敗したパッケージ名で検索して、そもそも存在するのか (typo も確認) と、前項で確認したバージョンで使用できるかを確認してください。

自分の場合、Debian で postgresql-client- で検索すると、以下のような感じでした。

  • postgresql-client-11
    • buster (oldstable)
  • postgresql-client-13
    • bullseye (stable)
    • bookworm (testing)
    • sid (unstable)

ということで、11 は使用できず、13 が使用可能であることが分かりました。

ラビット・チャレンジ - Stage 3. 深層学習 前編 (Day 1)

提出したレポートです。 絶対書きすぎですが、行間を埋めたくなるので仕方ない。 Rabbit Challenge - Stage 3. 深層学習 前編 (Day 1) 0. 深層学習とは何か この講義(Day1)の内容では、ニューラルネットワークを用いた学習方法として、順...