はじめに 本記事では、ERROR: no matching manifest for linux/arm64/v8 in the manifest list entriesの解決方法を記述します。 コード docker-compose.yml version: '3' services: db: image: mysql:8.0 command: --default-authentication-plugin=mysql_native_password volumes: - ./src/db/mysql_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: password web: build: . command: bundle exec rails s -p 3000 -b '0.0.0.0' volumes: - ./src:/app ports: - "3000:3000" depends_on: - db Dockerfile FROM ruby:2.7 ENV RAILS_ENV=production RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - \ && echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list \ && apt-get update -qq \ && apt-get install -y nodejs yarn WORKDIR /app COPY ./src /app RUN bundle config --local set path 'vendor/bundle' \ && bundle install COPY start.sh /start.sh RUN chmod 744 /start.sh CMD [ "sh", "/start.sh" ] ターミナルにて % docker-compose run web rails new . --force --database=mysql Creating network "rails_docker_default" with the default driver Pulling db (mysql:8.0)... 8.0: Pulling from library/mysql ERROR: no matching manifest for linux/arm64/v8 in the manifest list entries ERROR: no matching manifest for linux/arm64/v8 in the manifest list entriesというエラーが発生しました。 結論 M1チップ問題でした。 何が良くて、何にエラーが出るのかイマイチわからないです。。 platform: linux/x86_64を追記しました。 docker-compose.yml version: '3' services: db: platform: linux/x86_64 # M1チップ対応のため追記 image: mysql:8.0 command: --default-authentication-plugin=mysql_native_password volumes: - ./src/db/mysql_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: password web: build: . command: bundle exec rails s -p 3000 -b '0.0.0.0' volumes: - ./src:/app ports: - "3000:3000" depends_on: - db ターミナルにて再度コマンド入力し、成功しました！ 以上です。 終わりに M1チップ問題なかなかややこしいですね。 随時対応していきましょう。 以下参考サイトです。 M1 Macでno matching manifest for linux/arm64/v8が発生した 明日も頑張ります。

自PCでは無く社内にあるサーバにDockerコンテナを多数起動してクライアントから直接コンテナにアクセスする方法（主に開発、社内サーバ用）。 dockerコンテナのポートを変えてdockerホストにマップしたり、dockerホストでproxyを建ててアクセスする方法はたくさん出てくるのですが、あまり出てこないので残しておきます。この方法のメリットは 用途別にホスト名が別けられることと、 http://servername:8080 のようにいちいちポート番号を考えなくても良いことです。 結論 ルータでコンテナIPへstaticルートを切る dockerサーバでip4をforwardする 構成図 下記のようなネットワークだった場合の例。 社内ネットワーク（クライアント、ルータ、サーバ） 192.168.0.0/24 dockerコンテナ（サーバ内のdockerコンテナ） 172.21.0.0/24 設定 今回の例では、クライアントからnginxコンテナに直接アクセスします。DockerサーバはLinux。 dockerコンテナ 下記のようにブリッジのネットワークを作って、コンテナにIPをつける。 docker-compose.yml version: '3.6' networks: share_nw: driver: bridge driver_opts: com.docker.network.bridge.name: docker1 ipam: driver: default config: - subnet: 172.21.0.0/24 services: nginx: image: nginx:latest networks: share_nw: ipv4_address: 172.21.0.10 ルータ 説明書を見てルータのLAN側 静的ルーティングを設定する。 今回の例では、ネットワーク：172.21.0.0/24 → ゲートウェイ：サーバのIP（192.168.0.10）にする。 例） https://www.asus.com/jp/support/FAQ/1011706/ Dockerサーバ IPv4 フォワーディングを有効にする。 sudo vi /etc/sysctl.conf net.ipv4.ip_forward=1 reboot 確認 クライアントPCから ping 172.21.0.10 とかしてみる。 ちょっと使いやすく 社内（簡易）DNSサーバを建てる dnsmasqと言う簡易DNSサーバのコンテナを起動し、各コンテナのIPを名前解決できるようにし、クライアントのDNSはdnsmasqのIPにしておく（ルータのDHCPでDNSをdnsmasqのIPを配るように設定する）。 dnsmasqは下記のような設定をしておく。 nginx-server.example.local 172.21.0.10 dnsmasq (docker hub) https://hub.docker.com/search?q=dnsmasq&type=image web経由でコンテナを起動/停止 Portainerがまぁまぁ使いやすい。web経由でコンテナを起動/停止、imageのpullや操作なんかができます。

はじめに 自分の勉強のために、何かしらのWEBアプリを作ろうかなと思っていた矢先、「まずはDBだ！」と思い立ちました。 そこで、本記事ではDockerを用いてPostgreSQLを立ち上げて、立ち上げが成功しているかどうかを確認するところまでの方法について書いていこうと思います。 この記事はあくまで自分の備忘録程度に使おうかなと考えているので、他の記事の内容と酷似していることも十分に有り得ますが、ご容赦ください。 また「この部分は違うよ！」みたいなものがあれば、コメントお待ちしております。 本記事でのファイル構成 本記事では、以下のような構成で作っていきます。 database └ init └ create_database.sql docker-compose.yml docker-compose.ymlファイルの作成 まずはdocker-compose.ymlファイルを作っていきます。 これは複数のDockerコンテナを使用する際に便利なものという認識でおり、今後の「WEBアプリ開発をしよう！」という目標に乗っかっていると考えたためです。 作ったものは以下のようになります。 docker-compose.yml # バージョン指定 version: '3.8' # サービスの定義 services: # PostgreSQLのコンテナの立ち上げ database: image: postgres:13.4 ports: - 5432:5432 volumes: - ./database/init:/docker-entrypoint-initdb.d environment: POSTGRES_USER: user POSTGRES_PASSWORD: password container_name: postgresql このうち、portsでは(ローカル環境でのポート番号):(コンテナでのポート番号)を指定しています。 PostgreSQLではポート番号のデフォルトが5432のため、このように指定していますが、既に5432ポートが使われているときなどは左側の数字を変更するといいはずです。 volumesは、:の前に指定されているディレクトリに含まれるファイルなどを、コンテナ内の:以降のディレクトリにて利用可能にするために指定するものです。 本記事だと、自身のローカル環境でのdatabase/initディレクトリ内にあるファイルが、Docker内の/docker-entrypoint-initdb.dというディレクトリ内に移されることになります。 PostgreSQLの公式Dockerイメージでは、/docker-entrypoint-initdb.dに置かれたsqlファイルが一度のみ実行されるので、特にこちら側で設定しない限りは、このディレクトリを必ず指定する必要があります。 実際に移されたことを確認するには、 $ docker exec -it (container_nameで指定した名前) /bin/bash を実行してコンテナ内に入り、 /# cd docker-entrypoint-initdb.d /docker-entrypoint-initdb.d# ls を実行することにより、確認できます。 environmentでは、データベースに入るためのrootユーザ名・パスワードを指定しています。 公式ドキュメントによるとPOSTGRES_PASSWORDは必須ですが、POSTGRES_USERは必須ではなく、その場合はユーザ名がpostgresになるそうです。 データベース構築のためのSQLファイルの作成 docker-compose.ymlを以上のように設定したら、次にdatabase/initディレクトリ内のcreate_database.sqlファイルを作成します。 create_database.sql /* DATABASEを作成 */ CREATE DATABASE test_db; 単純に、test_dbという名前のデータベースを作るように指示するSQLファイルです。 先程の説明の通り、database/initディレクトリ内にあるsqlファイルがデータベース立ち上げ時に実行されるので、このファイルによりPostgreSQLのコンテナ内にtest_dbというデータベースが構築されます。 Dockerコンテナの起動 以上の準備が整ったら、次のコマンドでDockerコンテナを起動します。 $ docker compose up -d コンテナが起動したら、以下のコマンドを順番に実行して、データベースtest_dbが作られていることを確認します。 $ docker exec -it postgresql /bin/bash # psql -U user psql (13.4 (Debian 13.4-4.pgdg110+1)) Type "help" for help. user=# \l Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+-------+----------+------------+------------+------------------- postgres | user | UTF8 | en_US.utf8 | en_US.utf8 | template0 | user | UTF8 | en_US.utf8 | en_US.utf8 | =c/user + | | | | | user=CTc/user template1 | user | UTF8 | en_US.utf8 | en_US.utf8 | =c/user + | | | | | user=CTc/user test_db | user | UTF8 | en_US.utf8 | en_US.utf8 | user | user | UTF8 | en_US.utf8 | en_US.utf8 | (5 rows) これで、PostgreSQLのコンテナ内にtest_dbデータベースが作成されたことが確認できました。 先述の通り、今回作成したsqlファイルは一度のみしか実行されないものです。 そのためデータベース内に新たにスキーマを作り、さらにテーブルを……と続けるには、コンテナを落とし、sqlファイルを追加して、コンテナを起動させて、という手順を踏まなくてはなりません。 いちいち$ docker compose downコマンドを叩くのも面倒ですし、せっかくのデータが消えてしまうのも癪なので、次はデータベースのマイグレーションを実行するためのDockerコンテナを作ってみようと思います。

はじめに Nuxt.js Rails Docker postgresqlで新規プロジェクトがあったのでその環境構築の備忘録 環境 macOS 前提条件 Dockerがインストールされている インストールされていない場合はこちらを参考にどうぞ ゴール localhost:3000にアクセスして下記画面がでる localhost:8080にアクセスして下記画面がでる ディレクトリ構成図 sample $ ├── sample ├── .env ├── .gitignore ├── docker-compose.yml ├── api │   　　├── Dockerfile │   　　├── Gemfile │   　　└── Gemfile.lock └── front └── Dockerfile ディレクトリ/ファイルの作成 sample $ mkdir sample sample $ mkdir {api,front} sample $ touch {docker-compose.yml,.env,.gitignore} api $ touch {Gemfile,Gemfile.lock,Dockerfile} front $ touch Dockerfile api/Dockerfile FROM ruby:2.7.1-alpine ARG WORKDIR ENV RUNTIME_PACKAGES="linux-headers libxml2-dev make gcc libc-dev nodejs tzdata postgresql-dev postgresql git" \ DEV_PACKAGES="build-base curl-dev" \ HOME=/${WORKDIR} \ LANG=C.UTF-8 \ TZ=Asia/Tokyo WORKDIR ${HOME} COPY Gemfile* ./ RUN apk update && \ apk upgrade && \ apk add --no-cache ${RUNTIME_PACKAGES} && \ apk add --virtual build-dependencies --no-cache ${DEV_PACKAGES} && \ bundle install -j4 && \ apk del build-dependencies COPY . . CMD ["rails", "server", "-b", "0.0.0.0"] api/Gemfile Gemfile source 'https://rubygems.org' gem 'rails', '~> 6.0.0' front/Dockerfile FROM node:14.4.0-alpine ARG WORKDIR ARG CONTAINER_PORT ENV HOME=/${WORKDIR} \ LANG=C.UTF-8 \ TZ=Asia/Tokyo \ HOST=0.0.0.0 WORKDIR ${HOME} EXPOSE ${CONTAINER_PORT} sample/docker-compose.yml docker-compose.yml version: "3.8" services: db: image: postgres:12.3-alpine environment: TZ: UTC PGTZ: UTC POSTGRES_PASSWORD: $POSTGRES_PASSWORD volumes: - ./api/tmp/db:/var/lib/postgresql/data api: build: context: ./api args: WORKDIR: $WORKDIR environment: POSTGRES_PASSWORD: $POSTGRES_PASSWORD volumes: - ./api:/$WORKDIR depends_on: - db ports: - "$API_PORT:$CONTAINER_PORT" front: build: context: ./front args: WORKDIR: $WORKDIR CONTAINER_PORT: $CONTAINER_PORT command: yarn run dev volumes: - ./front:/$WORKDIR ports: - "$FRONT_PORT:$CONTAINER_PORT" depends_on: - api sample/.env # api/front WORKDIR=app CONTAINER_PORT=3000 API_PORT=3000 FRONT_PORT=8080 # db POSTGRES_PASSWORD=password sample/.gitignore /.env *.envファイルをgitの管理下から外します Dokerイメージの生成 sample $ docker-compose build 失敗例 Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? ※dockerデスクトップを立ち上げて再度、docker-compose buildを実行 Dockerイメージの確認 sample $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE sample_api latest b19d75f43738 About a minute ago 561MB sample_front latest 9f9a253cb41e 47 hours ago 115MB Railsをapiモードで生成する sample $ docker-compose run --rm api rails new . -f -B -d postgresql --api create app create app/assets/config/manifest.js create app/assets/stylesheets/application.css create app/channels/application_cable/channel.rb create app/channels/application_cable/connection.rb create app/controllers/application_controller.rb create app/helpers/application_helper.rb create app/javascript/channels/consumer.js create app/javascript/channels/index.js create app/javascript/packs/application.js create app/jobs/application_job.rb............. Gemfileの確認 sample/api/Gemfile source 'https://rubygems.org' git_source(:github) { |repo| "https://github.com/#{repo}.git" } ruby '2.7.1' # Bundle edge Rails instead: gem 'rails', github: 'rails/rails', branch: 'main' gem 'rails', '~> 6.0.4', '>= 6.0.4.1' # Use postgresql as the database for Active Record gem 'pg', '>= 0.18', '< 2.0' # Use Puma as the app server gem 'puma', '~> 4.1' # Build JSON APIs with ease. Read more: https://github.com/rails/jbuilder # gem 'jbuilder', '~> 2.7' # Use Redis adapter to run Action Cable in production # gem 'redis', '~> 4.0' # Use Active Model has_secure_password # gem 'bcrypt', '~> 3.1.7' # Use Active Storage variant # gem 'image_processing', '~> 1.2' # Reduces boot times through caching; required in config/boot.rb gem 'bootsnap', '>= 1.4.2', require: false # Use Rack CORS for handling Cross-Origin Resource Sharing (CORS), making cross-origin AJAX possible # gem 'rack-cors' group :development, :test do # Call 'byebug' anywhere in the code to stop execution and get a debugger console gem 'byebug', platforms: [:mri, :mingw, :x64_mingw] end group :development do gem 'listen', '~> 3.2' # Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring gem 'spring' gem 'spring-watcher-listen', '~> 2.0.0' end # Windows does not include zoneinfo files, so bundle the tzinfo-data gem gem 'tzinfo-data', platforms: [:mingw, :mswin, :x64_mingw, :jruby] railsアプリを生成したことによりGemfileが書き変わっています apiのdockerイメージを再度buildする sample $ docker-compose build api 公式ドキュメントよりGemfile/Dockerfileを変更した場合はイメージを再ビルドする必要があると記載がある API(Rails)DB設定 api/app/config/database.yml default: &default adapter: postgresql encoding: unicode host: db # 追加 username: postgres # 追加 password: <%= ENV["POSTGRES_PASSWORD"] %> # 追加 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> 設定完了後、DBを作成する sample $ docker-compose run api bundle exec rails db:create # 成功 Created database 'app_development' Created database 'app_test' apiコンテナ起動確認(Rails) sample $ docker-compose up api sample-api-1 | * Min threads: 5, max threads: 5 sample-api-1 | * Environment: development sample-api-1 | * Listening on tcp://0.0.0.0:3000 sample-api-1 | Use Ctrl-C to stop http://localhost:3000へアクセスし下記が画面が出るか確認 apiコンテナ停止 新規でターミナルを立ち上げsampleディレクトリへ移動する sample $ docker-compose down api [+] Running 4/4 ⠿ Container sample_api_run_184a69330fa1 Removed 0.1s ⠿ Container sample-api-1 Remo... 0.3s ⠿ Container sample-db-1 Remov... 0.2s ⠿ Network sample_default Remo... 0.1s Nuxt.jsを生成する sample $ docker-compose run --rm front yarn create nuxt-app --overwrite-dir . Nuxt.jsはアプリを生成する時に複数(12個)の質問が返されます 今回は下記設定でNuxt.jsを生成します 質問1 ? Project name:sample 質問2 ? Programming language:javaScript 質問3 ? Package manager:yarn 質問4 ? UI framework:vuetify.js 質問5 ? Nuxt.js modules:Axios - Promise based HTTP client 質問6 ? Linting tools:ESLint 質問7 ? Testing framework: None 質問8 ? Rendering mode: Single Page App 質問9 ? Deployment target: Server (Node.js hosting) 質問10 ? Development tools: jsconfig.json (Recommended for VS Code if you're not usingtypescript) 質問11 ? Continuous integration: None 質問12 ? Version control system: Git # 成功 ? Successfully created project smple 今回は上記設定でNuxt.jsを生成します frontコンテナ起動確認(Nuxt.js) sample $ docker-compose up front http://localhost:8080へアクセスし下記が画面が出るか確認 お疲れ様でした

私の凡ミス集その①です。 Formタグ外に登録ボタンを配置した事が原因で、 登録ボタンが反応しなくなる。 環境 PHP7 Laravel6 Docker 背景 ユーザー登録画面と処理機能作成時の凡ミス 登録ボタンを押しても反応無し。エラーすら出ない。笑 RegisterController.phpを確認しても問題は見当たらない Web.phpの記述は、Auth::routes();で認証系はバッチリ register.blade.phpの記述を見ても、この時点では間違いが見当たらず 諦めて就寝... 解決 翌朝register.blade.phpを再確認したところ、 Formタグ外に登録ボタンを間違って配置していたおかげで、 入力データがPOSTされていない事を確認。 register.blade.php </div> </form> <button class="btn btn-block" title="アカウント登録" type="submit"> はじめる </button> <div> アカウントをお持ちの方は<a href="{{ route('login') }}">こちら</a>から </div> </div> 以下のように修正したら、上手くいった。 register.blade.php </div> 　　　　　　　　　　<button class="btn btn-block" title="アカウント登録" type="submit"> 　はじめる 　　　</button> </form> <div> アカウントをお持ちの方は<a href="{{ route('login') }}">こちら</a>から </div> </div> 終わりに Formタグの中でPOSTメソッドを定義して登録処理を実行しているので、 登録ボタンをタグ内に置かないと機能しないのは当たり前。 また、この事象はユーザー登録機能に関わらず、ログイン、パスワードリセット、投稿等、 あらゆるPOSTメソッドを使用する処理で起こりうる凡ミスです。 register.blade.php <form method="POST" action="{{ route('register') }}" class="p-3"> @csrf 　　　　　・・・・省略・・・・ <button class="btn btn-block" title="アカウント登録" type="submit"> はじめる </button> </form> 以上、凡ミス集①でした

前回は コチラ Laravel に変更します Java(Spring) ではなく PHP のスキルが必要になり、復習のため テーブル定義は前回のものから変更しません が、user テーブルの変更は必須なので後で更新する 今回の記事ではチュートリアルに即したログイン画面の実装をしていきます 記事の体裁は前回を踏襲 その他も変更します DB は PostgreSQL にします Laravel の開発環境構築は コチラ にて解説 docker-compose.yml 等は github/sosobl/env-laravel にて ログインを実装してみよう laravel-admin を使用します 他のライブラリも検討しましたが、ドキュメントの多さとそこまで複雑なことをやる必要もないため、本ライブラリを選定しました ログイン後のダッシュボード画面も付いてくるのが助かる 以下ドキュメントよりインストール実施 やったこと（コマンドログ） $ composer require encore/laravel-admin $ php artisan vendor:publish --provider="Encore\Admin\AdminServiceProvider" /config/app.php の timezone を Asia/Tokyo に、locale を ja に修正 $ php artisan admin:install これをやると初期アカウントの作成等のシーディングをしてくれる つまった点 SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "sessions" does not exist LINE 1 解決策 以下コマンドを実行し sessions テーブルを作成し、サーバー再起動 $ php artisan session:table 動作確認 http://localhost/admin/ へアクセス id:admin / pass:admin でログイン こんな画面が表示される （備忘録）ログインを実装してみよう（JetStream） ※ laravel-admin を使用した方が色々と捗るので、以下の記事は 備忘録として 残しておりますが以降は使用しません 一般ユーザーのような階層を設ける場合は使うかも 以下チュートリアルを行う 使用するライブラリは Laravel Jetstream にしました コマンド打ってインストールするだけで以下機能が追加されるため（簡単） ログインフォーム 認証 新規ユーザー登録 パスワード問い合わせ チーム管理（一応） API サポート（一応） インストール方法 $ composer require laravel/jetstream Laravel Jetstream の有効化 $ php artisan jetstream:install livewire --teams Laravel Jetstream のインストール（Livewire ） $ npm install && npm run dev $ php artisan migrate $ php artisan vendor:publish --tag=jetstream-views 日本語化 https://github.com/Laravel-Lang/lang/ から zip ダウンロード zip を解凍し lacales/ja 内のファイルをプロジェクト内の resources/ja にコピー、ja.json を resources/ にコピー config/app.php の locale を 'ja' に変更 インストール方法詳細は後ほど追記したい 参考 Laravel Docs Jetstream Docs

Dockerコンテナで立ち上げたSonarQubeを日本語化していきたいと思います。 Dockerじゃなくても手順は同じハズ・・・。 参考にした記事 - https://mebee.info/2020/04/14/post-9166/ 環境 Windows10 Pro Windows10 へDockerインストールについては コチラ を参照 SonarQube Dockerコンテナ作成については コチラ の記事を参照 SonarQube日本語化 SonarQubeへアクセス ブラウザを開いて、SonarQubeへアクセスします。 http://{IP or ホスト名}/ 特に設定していなければhttp://localhost:9000/でアクセスできると思います。 ログイン ID：admin Password：admin でログイン可能です。 Marketplaceへ遷移 画面上部にある『Administration』をクリックする 『Marketplace』をクリック 日本語化Pulginをインストール 『Plugins』のちょい下にあるテキストボックスに『japan』を入力する 検索ができたら、『Install』をクリックします。 インストールが終わると画面上部に『Restart Server』が表示されるので、サーバを再起動します。 日本語化されているか確認 画面を更新すると、ログイン画面に戻されると思うので、再びログインします。 この時点で一応日本語化されているのが確認できます。 ログインします。 完全ではないものの一部日本語化されています。 あとがき パーッと画面遷移したところだと、リセットとか簡単な単語は翻訳されている印象でした。 手順自体はそんな難しくないと思うので、時間があれば適用する。くらいがいいかもしれませんね。 あとは、日本語化して誤解を生むような文章になってないことを祈るばかりですｗ 関連記事 SonarQubeをDockerで立ち上げた時の話 SonarQube＋WindowsでPHPソースをスキャンする

今まで問題なく接続できていたのに ある日突然 localhostに接続出来なくなりました。 100回くらい見たこの顔！ 今後同じ問題が起こったときのためにこちらに記載しておきます。 　環境 　Windows 10 　PHP ：8.0.8 　Laravel：8.55.0 　docker + Laravel sail 試したこと 他のアプリで確認→問題なく接続 .envファイルのAPP_PORT=でPORT番号変更→接続不可 セキュリティーソフトのファイヤーウォール設定解除→接続不可 git commitのバージョンを動作していた時間帯に戻す→接続不可 上記色々試しましたが上手く行かず... 解決 Composerのキャッシュを消して再インストール 参考サイト https://stackoverflow.com/questions/65486205/uwsgi-entered-fatal-state-too-many-start-retries-too-quickly-in-docker-contai 　キャッシュのクリア sail composer clearcache 　再インストール sail composer install dockerの起動 sail up -d これで問題なく接続しました

English Version (英語版) 機械学習モデルをGPUデバイスや組み込み機器などに実装することは、とても良い方法の一つです。 しかし、その一方で、非常にコストがかかります。 そこで、NVIDIA Jetson Nano Developer Kit B01を使って、物体検出モデル(Pytorch)と認識モデル(Tensorflow-Keras)を実行し、コスト削減を図りました。 しかし、Jetson nanoに展開するために最適化されたモデルを使用しても、メモリを多く消費するようで、同じデバイス上で両方のモデルを実行することは非常に困難でした。そこで、1つのモデルをAWSのクラウドシステムを利用して展開することにしました。 Jetson Nano上の検出モデルとAWS Cloud Services（AWS）上の認識モデルにより、システム全体の性能と速度を向上させることができました。 次の図は、組み込み機器とAWSへのモデル展開について説明しています: 今回は、AWS Lambda関数、docker、Cloudformationを利用しました。Lambda関数とdockerイメージは、AWS Cloudformation pipelineを使って自動的に作成されます。Cloudformation pipelineはyamlファイルを使って作成します。JSONフォーマットを利用することにもできますが、Cloudformationを扱う上でYAMLはJSONよりも多くの利点があります。 Dockerfileを作成する。 こちらがdockerfileの例です。 # ベースイメージにpython 3.8のLambdaランタイムを使用 FROM public.ecr.aws/lambda/python:3.8 # 変数の格納にはArgumentを使用 ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI ARG AWS_DEFAULT_REGION # このapp.pyが機械学習の推論スクリプトになります。 COPY app.py ./ # requirements.txtからpythonの要件をインストールします。 RUN python3.8 -m pip install -r requirements.txt # CMDをラムダ関数ハンドラに設定する CMD ["app.handler"] このDockerfileは、次のセクションで説明するCloudformationパイプラインを実行すると、イメージが作成されます。 Dockerについてもっと知りたい方は、こちらをご覧ください。 Cloudformationを使ったパイプラインテンプレートの作成 AWSでは、各サービスについて非常に優れたドキュメントを用意しています。そこで、Lambda関数の作成にはAWS::Lambda::Functionのドキュメントを使用します。 パラメータテンプレートスニペットの設定は以下のように行います: Note：この方法では、各オプションのデフォルト名を設定することができます。例えば、アプリケーション名、S3バケット名、dockerイメージ名、ラムダ関数名などです。パラメーターセクションで名前を設定しないと、パイプラインを実行すると、長くて気持ち悪い名前が作成されてしまいます。 pipeline.yml AWSTemplateFormatVersion: 2010-09-09 Parameters: ApplicationName: Default: project_name_abc Type: String Description: Enter the name of your application CodeBuildImage: Default: 'aws/codebuild/standard:2.0' Type: String Description: Name of CodeBuild image. SourceBranch: Default: 'master' Type: String Description: Name of the branch. Environment: Default: 'development'(or 'production') # We can change depending on the environment Type: String Description: The environment to build. LambdaFunction: Default: 'lambda-function-name' Type: String Description: The predict lambda name. 基本的なスニペットを作成したら、今度はパイプライン用のResourcesを作成します。Resourcesを書く前に注意すべき点があります: 1. リポジトリ名は、命名規則に従ってください。 2. 名前はアルファベットで始まり、アルファベットの小文字、数字、ハイフン、アンダースコア、スラッシュのみを含むことができます。 3. すべてのリソースにAWS::IAM:Roleを与えることが推奨されます。 4. Amazon CloudWatchは、AWS、ハイブリッド、オンプレミスのアプリケーションやインフラリソースのデータや実用的なインサイトを提供する監視・管理サービスです。CloudWatchは、アプリケーション、インフラ、サービスといったスタック全体を監視し、アラーム、ログ、イベントデータを活用して自動化されたアクションを取ることができます。 5. AWS::CodeBuild::Projectリソースは、AWS CodeBuildがどのようにソースコードをビルドするかを設定します。 6. ルートレベルで buildspec.yamlを用意します。 7. AWS::CodePipeline::Pipelineリソースは、ソフトウェアの一部が変更されたときに、リリースプロセスがどのように機能するかを説明するパイプラインを作成します。 8. AWS::Lambda::Functionでは、Lambda関数を作成しています。実行時にLambda関数が使用できる最大メモリは10GBです。 pipeline.yml Resources: SourceRepository: Type: 'AWS::CodeCommit::Repository' Properties: RepositoryName: !Sub '${ApplicationName}-${Environment}' RepositoryDescription: !Sub 'Source code for ${ApplicationName}' MyRepository: Type: AWS::ECR::Repository Properties: RepositoryName: !Sub '${ApplicationName}-${Environment}/repository_name' CodeBuildRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: - 'sts:AssumeRole' Effect: Allow Principal: Service: - codebuild.amazonaws.com CodeBuildPolicy: Type: 'AWS::IAM::Policy' Properties: PolicyName: CodeBuildPolicy PolicyDocument: Version: 2012-10-17 Statement: - Action: - 'logs:CreateLogGroup' - 'logs:CreateLogStream' - 'logs:PutLogEvents' Resource: '*' Effect: Allow Roles: - !Ref CodeBuildRole MyContainerBuild: Type: 'AWS::CodeBuild::Project' Properties: Artifacts: Type: CODEPIPELINE Environment: ComputeType: BUILD_GENERAL1_SMALL # ビルドには最大で3GBのメモリと2つのvCPUを使用します。 Image: !Ref CodeBuildImage Type: LINUX_CONTAINER PrivilegedMode: True EnvironmentVariables: - Name: REPOSITORY_URI # 環境変数で設定できます（本記事では説明していません）。 Value: !Sub '${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${MyRepository}' - Name: ENVIRONMENT # Not covered in this article Value: !Sub '${Environment}' Name: !Sub '${ApplicationName}-${Environment}-MyContainer-Build' ServiceRole: !GetAtt - CodeBuildRole - Arn Source: Type: CODEPIPELINE BuildSpec: 'buildspec.yaml' AppPipeline: Type: 'AWS::CodePipeline::Pipeline' Properties: Name: !Sub '${ApplicationName}-${Environment}-Pipeline' ArtifactStore: Type: S3 Location: !Ref ArtifactBucketStore RoleArn: !GetAtt - CodePipelineRole - Arn Stages: - Name: Source Actions: - ActionTypeId: Category: Source Owner: AWS Version: '1' Provider: CodeCommit Configuration: BranchName: !Ref SourceBranch RepositoryName: !GetAtt - SourceRepository - Name OutputArtifacts: - Name: SourceRepo RunOrder: 1 Name: Source - Name: Build-Containers Actions: - InputArtifacts: - Name: SourceRepo Name: Build-My-Container ActionTypeId: Category: Build Owner: AWS Version: '1' Provider: CodeBuild Configuration: ProjectName: !Ref MyContainerBuild RunOrder: 1 CodePipelineRole: Type: 'AWS::IAM::Role' Properties: Policies: - PolicyName: DefaultPolicy PolicyDocument: Version: 2012-10-17 Statement: - Action: - 'codecommit:CancelUploadArchive' - 'codecommit:GetBranch' - 'codecommit:GetCommit' Resource: '*' Effect: Allow - Action: - 'cloudwatch:*' - 'iam:PassRole' Resource: '*' Effect: Allow - Action: - 'lambda:InvokeFunction' - 'lambda:ListFunctions' Resource: '*' Effect: Allow - Action: - 'codebuild:BatchGetBuilds' - 'codebuild:StartBuild' Resource: '*' Effect: Allow AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: - 'sts:AssumeRole' Effect: Allow Principal: Service: - codepipeline.amazonaws.com LambdaFunctionRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: "/" Policies: - PolicyName: LambdaFunctionPolicy PolicyDocument: Version: '2012-10-17' Statement: - Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: '*' Effect: Allow - Action: - 'lambda:InvokeFunction' - 'lambda:InvokeAsync' Resource: '*' Effect: Allow LambdaFunction: Type: 'AWS::Lambda::Function' Properties: FunctionName: !Sub '${ApplicationName}-${MyLambda}-${Environment}' MemorySize: 4096 Timeout: 500 Role: !GetAtt LambdaFunctionRole.Arn Code: ImageUri: !Sub '${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${MyRepository}:latest' PackageType: Image Environment: Variables: S3BUCKETNAME: !Sub ${BucketName} S3BUCKETREGION: !Sub ${AWS::Region} さて、CloudFormationのテンプレートを用意したら、いよいよスタックの作成です。 まず、「Upload a template file」オプションを選択し、pipeline.yml ファイルを選択します。 スタック名の入力: (スタック名には、アルファベット（A-Z、a-z）、数字（0-9）、ダッシュ（-）が使用できます。) また、パイプラインの作成時に設定したすべてのパラメータを確認することができます。 そして最後に、スタックを作成しましょう。 問題やエラーがなければ、dockerイメージが作成され、Elastic Container Registry にアクセスできるようになります。 Lambda関数が作成できたら、次にAWSコンソールから最新版のdockerイメージを手動でデプロイする必要があります。latestのDockerイメージを選択します。現在のところ、Cloudformation pipelineのビルドから自動的にイメージをデプロイすることはできません。 以上、ご紹介しました。

日本語版 (Japanese Version) Implementing machine learning models on GPU devices, embedded devices, etc. is the best option. But on the other hand, it is very costly. The following figure explained about the models deployment on embedded device and AWS: Therefore, I used NVIDIA Jetson Nano Developer Kit B01 to run object detection model (Pytorch) and recognition model (Tensorflow-Keras). I used an optimized model to deploy on Jetson nano but it seems memory hungry and it is very difficult to run both models on same device. Hence, I decided to use AWS cloud system to deploy atleast one model. The detection model on Jetson Nano and Recognition Model on AWS Cloud Services (AWS) helped me to improve the performance and speed of the overall system. For this, I used AWS Lambda function, docker repository and Cloudformation. Lambda function and docker repository will be automatically created by using AWS Cloudformation pipeline. Cloudformation pipeline is created using yaml file. There is no restrictions of using JSON format too but YAML have many advantages over JSON while working on Cloudformation. Creating a Dockerfile: This is just a sample dockerfile. # Pull the base image with python 3.8 as a runtime for your Lambda FROM public.ecr.aws/lambda/python:3.8 # Use Argument to store variables ARG AWS_CONTAINER_CREDENTIALS_RELATIVE_URI ARG AWS_DEFAULT_REGION # This app.py will be the machine learning inference script. COPY app.py ./ # Install the python requirements from requirements.txt RUN python3.8 -m pip install -r requirements.txt # Set the CMD to your lambda function handler CMD ["app.handler"] This Dockerfile will create an image once we run the Cloudformation pipeline which is explained in the next section. Need to know more about Docker, please check here. Creating a Pipeline Template using Cloudformation: AWS has prepared a very good documentation for each services. Therefore, I will use AWS::Lambda::Function documentation for creating a Lambda function. We can setup Parameters Template Snippets as below: Note: This way we can set the default name for each options. For example, Application name, S3 bucket name, docker repository name, lambda function name, etc. If we don't setup the name in the Parameters section, then once we run the pipeline, it will create a scary and long names. pipeline.yml AWSTemplateFormatVersion: 2010-09-09 Parameters: ApplicationName: Default: project_name_abc Type: String Description: Enter the name of your application CodeBuildImage: Default: 'aws/codebuild/standard:2.0' Type: String Description: Name of CodeBuild image. SourceBranch: Default: 'master' Type: String Description: Name of the branch. Environment: Default: 'development'(or 'production') # We can change depending on the environment Type: String Description: The environment to build. LambdaFunction: Default: 'lambda-function-name' Type: String Description: The predict lambda name. Once we create a basic snippet, we will now create a Resources for the pipeline. Some important points to be noted before writing the Resources: 1. Repository name should follow the name convention. 2. The name must start with a letter and can only contain lowercase letters, numbers, hyphens, underscores, and forward slashes. 3. It is a good practice to give AWS::IAM:Role for every Resources. 4. Amazon CloudWatch is a monitoring and management service that provides data and actionable insights for AWS, hybrid, and on-premises applications and infrastructure resources. CloudWatch enables you to monitor your complete stack (applications, infrastructure, and services) and leverage alarms, logs, and events data to take automated actions. 5. The AWS::CodeBuild::Project resource configures how AWS CodeBuild builds the source code. 6. Provide a buildspec.yaml at the root level 7. The AWS::CodePipeline::Pipeline resource creates a pipeline that describes how release process works when a piece of software changes. 8. The AWS::Lambda::Function creates a Lambda function. The maximum memory available to the Lambda function during runtime is 10GB. pipeline.yml Resources: SourceRepository: Type: 'AWS::CodeCommit::Repository' Properties: RepositoryName: !Sub '${ApplicationName}-${Environment}' RepositoryDescription: !Sub 'Source code for ${ApplicationName}' MyRepository: Type: AWS::ECR::Repository Properties: RepositoryName: !Sub '${ApplicationName}-${Environment}/repository_name' CodeBuildRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: - 'sts:AssumeRole' Effect: Allow Principal: Service: - codebuild.amazonaws.com CodeBuildPolicy: Type: 'AWS::IAM::Policy' Properties: PolicyName: CodeBuildPolicy PolicyDocument: Version: 2012-10-17 Statement: - Action: - 'logs:CreateLogGroup' - 'logs:CreateLogStream' - 'logs:PutLogEvents' Resource: '*' Effect: Allow Roles: - !Ref CodeBuildRole MyContainerBuild: Type: 'AWS::CodeBuild::Project' Properties: Artifacts: Type: CODEPIPELINE Environment: ComputeType: BUILD_GENERAL1_SMALL # Use up to 3 GB memory and 2 vCPUs for builds. Image: !Ref CodeBuildImage Type: LINUX_CONTAINER PrivilegedMode: True EnvironmentVariables: - Name: REPOSITORY_URI # It can be set in the environment variables (Not covered in this article) Value: !Sub '${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${MyRepository}' - Name: ENVIRONMENT # Not covered in this article Value: !Sub '${Environment}' Name: !Sub '${ApplicationName}-${Environment}-MyContainer-Build' ServiceRole: !GetAtt - CodeBuildRole - Arn Source: Type: CODEPIPELINE BuildSpec: 'buildspec.yaml' AppPipeline: Type: 'AWS::CodePipeline::Pipeline' Properties: Name: !Sub '${ApplicationName}-${Environment}-Pipeline' ArtifactStore: Type: S3 Location: !Ref ArtifactBucketStore RoleArn: !GetAtt - CodePipelineRole - Arn Stages: - Name: Source Actions: - ActionTypeId: Category: Source Owner: AWS Version: '1' Provider: CodeCommit Configuration: BranchName: !Ref SourceBranch RepositoryName: !GetAtt - SourceRepository - Name OutputArtifacts: - Name: SourceRepo RunOrder: 1 Name: Source - Name: Build-Containers Actions: - InputArtifacts: - Name: SourceRepo Name: Build-My-Container ActionTypeId: Category: Build Owner: AWS Version: '1' Provider: CodeBuild Configuration: ProjectName: !Ref MyContainerBuild RunOrder: 1 CodePipelineRole: Type: 'AWS::IAM::Role' Properties: Policies: - PolicyName: DefaultPolicy PolicyDocument: Version: 2012-10-17 Statement: - Action: - 'codecommit:CancelUploadArchive' - 'codecommit:GetBranch' - 'codecommit:GetCommit' Resource: '*' Effect: Allow - Action: - 'cloudwatch:*' - 'iam:PassRole' Resource: '*' Effect: Allow - Action: - 'lambda:InvokeFunction' - 'lambda:ListFunctions' Resource: '*' Effect: Allow - Action: - 'codebuild:BatchGetBuilds' - 'codebuild:StartBuild' Resource: '*' Effect: Allow AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Action: - 'sts:AssumeRole' Effect: Allow Principal: Service: - codepipeline.amazonaws.com LambdaFunctionRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole Path: "/" Policies: - PolicyName: LambdaFunctionPolicy PolicyDocument: Version: '2012-10-17' Statement: - Action: - logs:CreateLogGroup - logs:CreateLogStream - logs:PutLogEvents Resource: '*' Effect: Allow - Action: - 'lambda:InvokeFunction' - 'lambda:InvokeAsync' Resource: '*' Effect: Allow LambdaFunction: Type: 'AWS::Lambda::Function' Properties: FunctionName: !Sub '${ApplicationName}-${MyLambda}-${Environment}' MemorySize: 4096 Timeout: 500 Role: !GetAtt LambdaFunctionRole.Arn Code: ImageUri: !Sub '${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/${MyRepository}:latest' PackageType: Image Environment: Variables: S3BUCKETNAME: !Sub ${BucketName} S3BUCKETREGION: !Sub ${AWS::Region} Now, once we prepare the CloudFormation template, it's time to create stack. We need to chose Upload a template file option and select the pipeline.yml file. Provide a stack name (Stack name can include letters (A-Z and a-z), numbers (0-9), and dashes (-).) We can also able to see all the parameters we set during creating pipeline. And finally, let's create the stack. If there is no issue or no errors, then a docker image will be created which can be accessed to Elastic Container Registry Once the Lambda function has been created, then we need to manually deploy the newest version of docker image from the AWS console. Select the latest docker image. Currently, it cannot deploy image automatically from the Cloudformation pipeline build. That's all for now!