なぜ記事を書くのか docker-composeを使ってアプリケーションを作成中に、使うソフトウェアをconda環境を使って作る必要性があった。 GPU環境で動かすため、dockerのイメージはnvidia/cuda:10.2-cudnn7-devel-ubuntu18.04を利用していたため、公式のAnacondaイメージは使えなかった(使う方法はあったかも) Anacondaをインストールして、作成したコンテナをactiveにする際に非常に手こずった 作成したcondaコンテナでアプリケーションを起動するのに非常に手こずった やること docker-composeにAnacondaをインストールする condaコンテナを作って、必要なライブラリをインストールする 作成したコンテナ内でアプリケーションを起動する Anacondaをインストールする FROM nvidia/cuda:10.2-cudnn7-devel-ubuntu18.04 USER root RUN apt-get update && apt-get install -y wget && apt-get update RUN wget https://repo.anaconda.com/archive/Anaconda3-2021.05-Linux-x86_64.sh RUN bash Anaconda3-2021.05-Linux-x86_64.sh -b && rm Anaconda3-2021.05-Linux-x86_64.sh ENV PATH $PATH:/root/anaconda3/bin RUN conda update -n base -c defaults conda 公式サイトからインストーラーのダウンロードURLをコピーしてくる wgetでDL、bashでインストール(-bオプションでインストール中のyesやenterをスキップする) -bオプションを使うとPATHが通らないため、ENVでPATHを通す なんかアラートが出るからupdateをする condaコンテナを作成して、Activeにする RUN conda create -n test SHELL ["conda", "run", "-n", "test", "/bin/bash", "-c"] RUN pip3 install update pip && pip3 install flask RUN conda init bash conda createで作成したいコンテナを作成する。 SHELL 〜で作成したコンテナをactiveにする その後にpip installするとコンテナ内にライブラリがインストールされる 作成したコンテナ内でアプリケーションを起動する WORKDIR /app COPY ./app /app CMD python3 app.py CMD python3 app.pyでアプリケーションを起動する ここが今回の肝です。 ずっと、CMD ["python3","app.py"]でアプリケーションを起動していたのですが、それだとinstallされているはずのライブラリがインストールされておらず、No module errorが発生してしまっていました。 色々調べている中で、CMD python3 app.pyでの実行の記述も見ていたのですが、同じこと書いてるわけだし関係ないか、と思ってスルーしていたのですが、ダメもとで試してみたら見事成功したので、目から鱗の発見でした。 今回の教訓 関係ないだろうと思っても試してみよう 一応docker-compose.yml docker-compose.yml version: '3' services: test: container_name: test build: ./digiclo-espnet ports: - "5000:5000" tty: true deploy: resources: reservations: devices: - capabilities: [gpu] logging: driver: "json-file" options: max-size: "10m" max-file: "1" restart: always ログがめちゃくちゃ溜まってしまうので、loggingは設定した方がいいです。 GPU環境で実行するために、deploy以下を記載してます

AWS,Docker 困ったこと 現状 https://qiita.com/at-946/items/1e8acea19cc0b9f31b98 このサイトを参考にDocker EC2でrailsアプリのデプロイを試みましたが、 $ scp -i ~/.ssh/myapp.pem ~/myapp/config/master.key myuser@xxx.xxx.xxx.xxx:./myapp/config/ scpコマンドでmaster.keyをリモートに送ろうとしましたがエラーが出ました。 scp: /master.key: Permission denied エラーメッセージです。 調べるとサーバーにkeyを設定する必要があるとのことなのでやってみましたが、結果は同じでした。 解決方法 myuserでの権限がなかった。 $ ls -l　 確認方法 権限の変え方 $ sudo chown -R myuser:myuser myapp

はじめに 表題の通りです。 SAM CLIからカスタムランタイムを使ってLambdaをデプロイの設定情報を作っていたのですが、ImageとZipどちらがいいのかわからずどちらも試しました。 今後どちらも選択的に使えるようにまとめておきます。 Zip 構成 lambda_rust ├──.aws-sam ├──samconfig.yaml ├──stock_data | ├──Cargo.lock | ├──Cargo.toml | ├──Makefile | └──src/main.rs └──template.yaml 設定 template.toml AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > Sample rust application for Lambda Resources: HelloRustFunction: Type: AWS::Serverless::Function Properties: FunctionName: HelloRust Role: arn:aws:iam::{Lambdaを実行するロール} PackageType: Zip CodeUri: ./stock_data Runtime: provided.al2 # Amazon Linux 2 Handler: bootstrap.is.real.handler Metadata: BuildMethod: makefile Makefile build-HelloRustFunction: cargo build --release --target x86_64-unknown-linux-musl # バイナリをbootstrapにして、Artifacts Directoryに格納する # Current Artifacts Directory : /workspace/stock_data/.aws-sam/build/HelloRustFunction cp ./target/x86_64-unknown-linux-musl/release/hello /workspace/stock_data/.aws-sam/build/HelloRustFunction/bootstrap samconfig.toml version = 0.1 [default] [default.deploy] [default.deploy.parameters] stack_name = "{ストック名}" s3_bucket = "{デプロイする先のS3バケット名}" region = "ap-northeast-1" confirm_changeset = false capabilities = ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM", "CAPABILITY_AUTO_EXPAND"] Cargo.toml [package] name = "stock_data" version = "0.1.0" authors = ["***** <****@****>"] edition = "2018" [dependencies] lambda_runtime = "0.4" lambda_http = "0.4.0" serde_json = "1.0.59" tokio = "1.11.0" [[bin]] name = "hello" path = "src/main.rs" main.rs use lambda_runtime::{handler_fn, Context, Error}; use serde_json::{json, Value}; // エントリポイント // Lambda特有のものを集約させる #[tokio::main] async fn main() -> Result<(), Error> { let func = handler_fn(my_handler); lambda_runtime::run(func).await?; Ok(()) } async fn my_handler(event: Value, _: Context) -> Result<Value, Error> { let first_name = event["firstName"].as_str().unwrap_or("world"); Ok(json!({ "message": format!("Hello, {}!", first_name) })) } #[cfg(test)] mod tests { use super::*; //async関数は#[test]では使用できない //#[test] #[tokio::test] async fn my_handler_response() -> Result<(), Error> { let event = json!({ "firstName": "AWS Lambda on Rust" }); let json = json!({ "message": "Hello, AWS Lambda on Rust!", }); let response = my_handler(event, Context::default()).await?; assert_eq!(response, json); Ok(()) } } 参考情報 AWS公式ブログがRust Runtime for AWSで書いています。makefileは使われていません。 こちらの資料、長いですが、219ページ目あたりからの方がブログより参考になりそう かなり参考にさせていただきました。makefileを利用し、かつ複数関数のデプロイが行われています。 Image 構成 lambda_rust ├──.aws-sam ├──samconfig.yaml ├──stock_data | ├──Cargo.lock | ├──Cargo.toml | ├──Dockerfile # Zipとの相違点 | └──src/main.rs └──template.yaml 設定 template.toml（Function名も変えていますが変える必要はないです） AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > Sample rust application for Lambda Resources: HelloRustFunctionImage: Type: AWS::Serverless::Function Properties: FunctionName: HelloRustImage Role: arn:aws:iam::{Lambdaを実行するロール} MemorySize: 512 CodeUri: ./stock_data 　　　　　　　　　　　　# Zipとの相違点 PackageType: Image 　　　　　　　　　　　　　　　　　　# Zipとの相違点 #Runtime: provided.al2 # Zipとの相違点 #Handler: bootstrap.is.real.handler # Zipとの相違点 Metadata: Dockerfile: Dockerfile 　　　　　　　　　　# Zipとの相違点 DockerContext: ./stock_data # Zipとの相違点 DockerTag: v1 　　　　　　　　　　　　　　　　　　　　　　　　　　　　# Zipとの相違点 Dockerfile FROM rust:latest as build-image WORKDIR /rust/stock_data COPY src/ /rust/stock_data/src/ COPY Cargo.toml Cargo.lock /rust/stock_data/ RUN rustup update && \ rustup target add x86_64-unknown-linux-musl RUN cargo build --release --target x86_64-unknown-linux-musl FROM public.ecr.aws/lambda/provided:al2 # 実行ファイルを起動するようにするため、ファイル名を "bootstrap" に変更する COPY --from=build-image /rust/stock_data/target/x86_64-unknown-linux-musl/release/hello ${LAMBDA_RUNTIME_DIR}/bootstrap # カスタムランタイムはハンドラ名利用しないため、適当な文字列を指定する。 CMD [ "lambda-handler" ] samconfig.toml version = 0.1 [default] [default.deploy] [default.deploy.parameters] stack_name = "{ストック名}" s3_bucket = "{デプロイする先のS3バケット名}" image_repository = "{ImageをpushするECRのリポジトリ}" # Zipとの相違点 region = "ap-northeast-1" confirm_changeset = false capabilities = ["CAPABILITY_IAM", "CAPABILITY_NAMED_IAM", "CAPABILITY_AUTO_EXPAND"] Cargo.toml # Zipと相違ないため略 main.rs // Zipと相違ないため略 参考情報 情報収集していて、Lambda+Rust+Imageでのデプロイは少ないように感じました。 一番参考にしたのは、AWS Toolkit for Visual Studio Codeのgo-imageのテンプレートでした。 VS CodeでコマンドではなくToolkitを使ってLambda関数を作成するとテンプレートとしてサンプルのhelloworldが生成されます。以下はそのテンプレートのgithubソースです。ビルドファイルをアップする必要があるRustにおいて、同じくビルドファイルを作成するGolangのtemplate.yamlやDockerfile書き方は非常に参考になりました。 プログラムビルドとビルドファイルを埋め込んだImageの作成を分けられていますが、RustでImageデプロイしている貴重な情報。 Lambdaのカスタムランタイム イメージの構成や環境変数まわりの確認に利用 余談 実は、これを試す前はDockerfileでかけるImageの方がデプロイ環境が把握しやすいのでImage派でした。 Zipを試してみたきっかけは、コンソールでソースが見れるのはZipという表示を見かけたからです。 Imageではソースをコンソール上からは見ることができない。 RustのZipをデプロイして、コンソールを確認してみました。 かなしい。 おわりに Zipでやりたかったコンソール上でのソースコードは見れませんでしたが、今後もZipで進めようと思います。 理由としては、Imageの場合（私の手順の場合）、Cargo build用にコンテナを立ちあげてデプロイする手順がありますが、私はVSCodeからコンテナに接続しその中でSAMを入れています。SAM実行にてさらにコンテナの中でコンテナが起動してCargo buildし、さらにもう一つコンテナを立ち上げてビルドファイルをコピーするという、SAMを実行しているコンテナと合わせて4つ同時にコンテナが起動します。実行時MacBookAirが数回死にました。 また、Zip手順ではsam buildを実行するとSAMを入れている環境、つまり私の場合だと開発環境のコンテナ内でCargo buildが行われますが、Imageでは、「SAM実行にてさらにコンテナの中でコンテナが起動してCargo build」の手順と完全に同じ事をしているに、コンテナが1つ余計に立ち上がるというデメリットしかないです。 もちろんその部分をMakefileに移し、最終的なビルドファイルの処理だけを切り替えればこれらのデメリットは無くなると思いますが、あまりにPCが死に過ぎてもうImageを試す気になれないのでZipで行こうと思います。 もう少しカスタムランタイム の中に持ち込みたい素材が増えてきたら変わってくる気がしますが、それまではZipで行こうと思います。

概要 Local開発環境を汚したくないのでDocker環境を作る Amplifyの使い方自体は紹介しません tree . ├── aws_configure │   ├── config │   └── credentials ├── docker │   ├── Dockerfile │   └── requirements.txt ├── src │ ├── amplify │ └── src ├── docker-compose.yml └── .gitignore Dockerfile FROM python:3.8-buster RUN apt update && apt -y upgrade \ && apt install -y nodejs npm \ && npm install -g @aws-amplify/cli # java for Amplify Mock RUN wget -O- https://apt.corretto.aws/corretto.key | apt-key add - RUN apt install -y software-properties-common \ && add-apt-repository --yes 'deb https://apt.corretto.aws stable main' \ && apt -y update && apt install -y java-11-amazon-corretto-jdk # COPY docker/requirements.txt /tmp/ # RUN pip install --upgrade pip && pip install -r /tmp/requirements.txt amplify mockを使用するため、Javaをインストールしています pythonで使いたいパッケージがあれば　docker/requirements.txt を用意して最後2行のコメントアウトを外してください 参考 * Amazon Corretto 11 のインストール手順 -AWS Doc * Install the Amplify CLI * はじめての Amplify デプロイまで -Qiita * Ubuntu Linuxで、add-apt-repositoryしようとして「コマンドがない」って言われたら docker-compose.yml version: '3' services: app: build: context: . dockerfile: docker/Dockerfile container_name: amplifyApp volumes: - ./src:/var/app - ./aws_configure:/root/.aws working_dir: /var/app tty: true ソースコード置き場と、aws設定ファイル置き場をvolumesに設定します aws_configure 以下のファイルは、amplify init すると作成されます チーム開発など、設定ファイルがすでにある場合はここに保存しておきます aws_configure/credentials はcommitすると大変まずいので、.gitignore で除外しましょう 起動 docker compose build docker compose up -d docker exec -it amplify-fastapi /bin/bash

困ったこと ローカルホスト(今回はlocalhost:3000)に接続しようとdocker-compose up -dしてもうまくいかない。 昨日gem追加したからそのせいかな、と思いつつも色々試行錯誤してなんとか解決しました。 今の状態を確認 docker-compose up -dをしたときは良さげな感じ。でもブラウザ見ると接続できてない。 $ docker-compose up -d Starting qiita_db_1 ... done Starting qiita_web_1 ... done docker-compose psでコンテナ一覧を表示してみるとStateがExit 7となっている。 $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------- qiita_db_1 docker-entrypoint.sh mysqld Up 3306/tcp, 33060/tcp qiita_web_1 bundle exec rails s -p 300 ... Exit 7 docker logs qiita_web_1で原因を探ってみる $ docker logs qiita_web_1 Could not find bcrypt-3.1.16 in any of the sources Run `bundle install` to install missing gems. ログ通りにbundle installしようとしたが、なんかうまくいかなかった。 解決方法 docker-compose buildしてからdocker-compose up -dする。 $ docker-compose build db uses an image, skipping Building web [+] Building 36.0s (13/13) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 37B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ruby:2.7.0 0.0s => [internal] load build context 0.7s => => transferring context: 10.46MB 0.7s => [1/8] FROM docker.io/library/ruby:2.7.0 0.0s => CACHED [2/8] RUN apt-get update -qq && apt-get install -y build-essential nodejs 0.0s => CACHED [3/8] RUN mkdir /app 0.0s => CACHED [4/8] WORKDIR /app 0.0s => [5/8] COPY Gemfile /app/Gemfile 0.1s => [6/8] COPY Gemfile.lock /app/Gemfile.lock 0.0s => [7/8] RUN bundle install 33.7s => [8/8] COPY . /app 0.3s => exporting to image 1.2s => => exporting layers 1.2s => => writing image sha256:963e2a37244ddae131525b434210cff12357decab259e971c5ec4edb27409498 0.0s => => naming to docker.io/library/qiita_web 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them $ docker-compose up -d qiita_db_1 is up-to-date Recreating qiita_web_1 ... done docker-compose psで再度コンテナを表示すると、StateがUpになった。 $ docker-compose ps Name Command State Ports ------------------------------------------------------------------------------------------------ qiita_db_1 docker-entrypoint.sh mysqld Up 3306/tcp, 33060/tcp qiita_web_1 bundle exec rails s -p 300 ... Up 0.0.0.0:3000->3000/tcp,:::3000->3000/tcp ブラウザで試してみると接続できるようになってるはず

非常に間抜けなことにこれに１日つぶしたので、ちゃんとブログに書いておく。 結論からすると非常に間抜けな結果なのだが調べている間はわからなかなったので、ソリューション含めて書いておく。 WSL2 のインストール WSL2のインストールは、Microsoft Store から行える。Ubuntuを選ぶ。 この時点で間違いが発生している。 Docker のインストール Docker のインストールの手順はInstall using the repository何も特殊なことはない。 ただ、このままだと、20.04 の場合は、docker の起動に失敗する。理由は、iptable の新しいバージョンがdocker とともにうまく動かない。であるので、次のようにして、古いバージョンを使う。 sudo update-alternatives --set iptables /usr/sbin/iptables-legacy sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy Failed to start service Docker on WSL2 $ sudo update-alternatives --config iptables [sudo] password for ushio: There are 2 choices for the alternative iptables (providing /usr/sbin/iptables). Selection Path Priority Status ------------------------------------------------------------ 0 /usr/sbin/iptables-legacy 20 auto mode * 1 /usr/sbin/iptables-legacy 20 manual mode 2 /usr/sbin/iptables-nft 10 manual mode しっかりと切り替わっている。dockerd を起動する INFO[2021-09-08T16:25:31.245371400-07:00] [graphdriver] using prior storage driver: overlay2 WARN[2021-09-08T16:25:31.264203900-07:00] Your kernel does not support cgroup memory limit WARN[2021-09-08T16:25:31.264788700-07:00] Unable to find cpu cgroup in mounts WARN[2021-09-08T16:25:31.265711400-07:00] Unable to find blkio cgroup in mounts WARN[2021-09-08T16:25:31.266660400-07:00] Unable to find cpuset cgroup in mounts WARN[2021-09-08T16:25:31.267471900-07:00] Unable to find pids cgroup in mounts INFO[2021-09-08T16:25:31.268758900-07:00] Loading containers: start. WARN[2021-09-08T16:25:31.282965200-07:00] Running iptables --wait -t nat -L -n failed with message: `iptables v1.8.4 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded.`, error: exit status 3 INFO[2021-09-08T16:25:31.505445700-07:00] stopping event stream following graceful shutdown error="<nil>" module=libcontainerd namespace=moby INFO[2021-09-08T16:25:31.508975100-07:00] stopping healthcheck following graceful shutdown module=libcontainerd INFO[2021-09-08T16:25:31.508988100-07:00] stopping event stream following graceful shutdown error="context canceled" module=libcontainerd namespace=plugins.moby WARN[2021-09-08T16:25:32.514096600-07:00] grpc: addrConn.createTransport failed to connect to {unix:///var/run/docker/containerd/containerd.sock <nil> 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial unix:///var/run/docker/containerd/containerd.sock: timeout". Reconnecting... module=grpc failed to start daemon: Error initializing network controller: error obtaining controller instance: failed to create NAT chain DOCKER: iptables failed: iptables -t nat -N DOCKER: iptables v1.8.4 (legacy): can't initialize iptables table `nat': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. (exit status 3) これが問題のあらまし。さてみなさんはどこが問題かおわかりだろうか？大変まぬけである。私は一日かけていろいろな問題を調査したが解決にいたらず途方に暮れていた。 同僚に助けを求めてみたら次の通りの回答だった。ちなみにほかの同僚は同じことをしてもちゃんと動くという。 解決編 最初に同僚がいってくれたのはuname -ar -a print all information そして　-r print the kernel release $ uname -ar Linux DESKTOP-N96ION0 4.4.0-19041-Microsoft #1151-Microsoft Thu Jul 22 21:05:00 PST 2021 x86_64 x86_64 x86_64 GNU/Linux ちなみに同僚のは Linux 5.10.16.3-microsoft-standard-WSL2+ 次に Powershell を開けて wsl- l -v ここで自分の愚かさに気づいたのだが、私のはWSL1だった。もうWSL2がでて相当経つのでデフォルトWSL2となぜか思い込んでいた。しかし、実際には、WSL2はデフォルトではなく、WSL2をデフォルトにする作業が必要である。 wsl -l -v NAME STATE VERSION * Ubuntu Running 1 あーもう。２にするぞ。 wsl --set-default-version 2 wsl --set-version Ubuntu 2 wsl -l -v NAME STATE VERSION * Ubuntu Running 2 Windows Subsystem for Linux Installation Guide for Windows 10 なぜはまったか？ 問題はなんでこんなくそしょうもないことで１日つぶしたかである。はっきり言ってこれを解くのになんの知識も必要ない「WSL2のインストール手順」だけの話だ。 ちなみにその間、iptable じゃなくて、bridge を使うようにしてみたり、いろんなログを調査したりとかめっちゃした。自分の脳みそどうなっとるんじゃと言いたくなる。 だって知識とちゃうから。自分の頭からWSL2はデフォルトではないが抜けていただけだから。 じゃあ、なんで解けなかったかというと、思い込みがあって、もっと難しい問題と思っていたことにあるから。多分何かをインストールするときはもう一度オフィシャルをさぐったほうがよさそうだ。自分が普段使い慣れてるやつでも。あと、同僚がやったみたいに、知らないことを調べようとするのではなくて、確実に一歩一歩進んでいるのかをコマンドで確認したほうがよさそうだ。さあ、今から仕事するか。５時だけど。