記事の概要 windows端末でDockerコマンドのailiasを設定しようと思ったところ、手間取ったためメモしました。 対象者 初めて、windows端末を触る人。 docker-composeなどのコマンドが長すぎると思う人。 方法 解決に至らなかった取り組み profileに、以下を記載したが、Set-Aliasが認識されなかった。 Set-Alias dc docker-compose https://mseeeen.msen.jp/windows-10-set-alias-automatically-in-powershell/ txt Set-Ailas : 用語 'Set-Ailas' は、コマンドレット、関数、スクリプト ファイル、 または操作可能なプログラムの名前として認識されません。 名前が正しく記述されていることを確認し、パスが含まれている場合はそのパスが正しい ことを確認してから、再試行してください。 コマンドマクロを使用する https://qiita.com/little_ha・・d_s/items/91d6bcb680eba10da835 Windowsではコマンドマクロという機能を使用して、aliasと同じ設定が可能。 .bash_profileに記載する 恥ずかしながら、bash_profileなどは、windows端末では機能しないということも知らなかったです。 https://qiita.com/kulikala/items/f736629497a974ca82cb 参考記事

はじめに 自分自身がOracle Linux OSにdocker-composeをインストールするのに手間取ったので備忘録も兼ねて書いておきます。 現状のdocker-composeは、インストールにpipが必要だったので、Docker Engine自体の上でdocker-composeを動かしていました。 下記のようにpipがうまく行かなかったりv1でarm64用バイナリがなかったりしました。 https://qiita.com/kure/items/d691bc6afd912bbbc545 linuxserver/docker-compose しかし、新たに登場したGolang製のdocker-compose v21 が、シングルバイナリかつarm64に対応していたのでインストールしてみました。 インストール # cli-plugins用ディレクトリを作成 $ mkdir $HOME/.docker/cli-plugins # ダウンロード&インストール # (最新バージョンは適宜 https://github.com/docker/compose/releases からご確認お願いします。) $ curl -sSL --fail https://github.com/docker/compose/releases/download/v2.0.0-rc.3/docker-compose-linux-arm64 -o ~/.docker/cli-plugins/docker-compose $ chmod +x ~/.docker/cli-plugins/docker-compose # インストール確認 (docker'-'composeのハイフンが消えてることに注目) $ docker compose version Docker Compose version v2.0.0-rc.3 ?docker-compose v2 とかで検索してると、docker-compose.ymlのバージョンに引っかかってしまうのでネーミングちょっと変えてほしかったですね... ↩

DynamoDBをローカルで操作する際のコマンド Dockerを使ってローカルでDynamoDBを操作する際に使ったコマンドを備忘として書きます。 対象テーブル:users コマンド(随時更新する予定) テーブルの中身を見る C:\Users\Hoge>aws dynamodb scan --profile default --endpoint-url http://127.0.0.1:8000/ --table-name users テーブル削除 C:\Users\Hoge>aws dynamodb delete-table --profile default --endpoint-url http://127.0.0.1:8000/ --table-name users テーブル一覧の取得 C:\Users\Hoge>aws dynamodb --profile default --endpoint-url http://127.0.0.1:8000/ list-tables 上記コマンドを実行する際の注意点 Dockerを使ってローカルでDynamodb操作をしたのですが、ローカルといえど事前にダミーのconfigとcredentialsを用意しないと「The config profile (default) could not be found」「Unable to locate credentials. You can configure credentials by running "aws configure".」といった感じでエラーが出ました(Windows) 下記コマンドを打ってダミーのcredentials, configを作成する必要がありそう。 C:\Users\Hoge>aws configure AWS Access Key ID [None]: dummy AWS Secret Access Key [None]: dummy Default region name [None]: dummy Default output format [None]: json

前回は コチラ ※ 2021/09/13 時点で未完 ログインを実装してみよう 以下チュートリアルを行う 上記チュートリアルだとインメモリにアカウントレコードを登録し、そのレコードに対し認証を行う MySQL を使用するように設定変更を行う 設定変更をして動作確認ができるように、テーブル定義だけ先に行うことにした テーブル定義 各テーブルについて所管を記述する 実際のテーブル定義書については後ほど公開するかも （少しずつ追記していきます） アカウント情報 テーブル名は「Account」 spring-boot-starter-security が提供してくれるアカウント情報テーブル（＝ User テーブル）の初期スキーマは以下 username:String ユーザー名称。DaoAuthenticationProvider に渡されて認証が行われる password:String パスワード。DaoAuthenticationProvider に渡されて認証が行われる enabled:boolean 論理削除フラグ。 accountNonExpired:boolean アカウントの有効性フラグ。 credentialsNonExpired:boolean 認証情報（通常はパスワード）の有効性フラグ。 最近の考え方だとパスワードの頻繁な変更は脆弱とのことなので、今はあまり使わないかな？ パスワードを忘れた時の対処とかに流用できそう。 accountNonLocked:boolean アカウントロックフラグ。 authorities:Collection<? extends GrantedAuthority> 役割。 一旦 String 配列で持ったあと、createAuthorityList() で GrantedAuthority の List 化 チュートリアル中だと、WebSecurityConfig#userDetailsService() の User.role("USER") で実行される 上記初期スキーマの内容で十分なので、このままテーブルを作成する 作成日、最終更新日ぐらいは追加しておく ちなみに org.springframework.security.core.userdetails.User エンティティクラスを提供してくれているので、使い方は Javadoc を参照 実装する際には一応継承して自作クラスを使用しようね 役割 DB にテーブルは作らない enum 型にして静的に持つことにした 取り得る値は以下 ROLE_USER 一般ユーザー ROLE_ADMIN 管理者 今の所、各役割で動作の振る舞いは変わらない。気が向いたらどこかの画面の実装で出し分けしてみる 役割テーブルを作って DB に格納 → アプリケーション起動時にメモリに格納 → 静的に運用、も考えたけど保持する情報が文字列だけなので不要と判断 各役割ごとに実施できる機能も DB で管理するならアリ エージェント テーブル名は「Agent」 スキーマは以下を想定 id:sequence PK。 name:String エージェント名称（会社名） top_url:String トップページURL login_url:String ログインURL エージェント担当者 テーブル名は「AgentRecruiter」 スキーマは以下を想定 id:sequence PK。 agent_id:int Agent テーブルの ID（外部キー） name:String 担当者名 email:String メールアドレス 企業 テーブル名は「Company」 スキーマは以下を想定 id:sequence PK。 name:String 企業名称 corporate_url:String コーポレートサイトの URL recruit_url:String 採用サイトの URL 企業の求人票 テーブル名は「CompanyJobPosting」 企業のマークダウン形式メモ テーブル名は「CompanyMarkdown」 企業の評価ポイント テーブル名は「CompanyEvaluationStandard」 選考ステップ DB にテーブルは作らない enum 型にして静的に持つことにした 取り得る値は以下 IN_BOX 候補 SCREENING 書類選考 PRIMARY 一次選考 SECONDARY 二次選考 FINAL 最終選考 選考ステップの中に後述の「選考ステータス」を持つ 選考ステータス DB にテーブルは作らない enum 型にして静的に持つことにした 取り得る値は以下 NEW 新規作成 IN_PLANNING 計画中・準備中 NOT_READY 実施予定なし WAITING 待機中 READY 準備完了 IN_PROGRESS 実施中 PENDING 保留中 REJECTED 拒否 CANCELED キャンセル COMPLETED 完了 メモ エンティティから DDL を自動生成し実行してくれるオプション spring.jpa.hibernate.ddl-auto=*** https://qiita.com/KenjiOtsuka/items/8450c407ba121fea8151 エンティティから DDL を自動生成する だけ のプラグイン JPA Schema Generator Plugin https://tosi-tech.net/2019/01/generate-mysql-ddl-from-jpa-entity-class/ https://github.com/Devskiller/jpa2ddl エンティティで使用するアノテーション一覧 https://qiita.com/ughirose/items/5d691adc677aa08636b8 DB のスキーマを HTML で出力 https://qiita.com/nabedge/items/e9325cf214a78e378aee Draw.io で ER 図を描ける https://qiita.com/Ooooooomin_365/items/3118c0c5fab4e100dd4f

実装したいこと ある記事を参考にgem 'kaminari'を導入してページネーション機能を作ろうとしておりました。 gemの導入後に、% docker-compose run web rails g kaminari:views bootstrap4コマンドを実行したところタイトルのようなエラーが発生したので解決に至るプロセスをまとめようと思います。 エラー内容 % docker-compose run web rails g kaminari:views bootstrap4 % docker-compose run web bundle exec rails g kaminari:views bootstrap4 Creating locat_web_run ... done Running via Spring preloader in process 29 /usr/local/bundle/gems/kaminari-core-1.2.1/lib/generators/kaminari/views_generator.rb:117:in `initialize': No such file or directory @ rb_sysopen - https://api.github.com/repos/amatsuda/kaminari_themes/git/refs/heads/master (Errno::ENOENT) from /usr/local/bundle/gems/kaminari-core-1.2.1/lib/generators/kaminari/views_generator.rb:117:in `open' from /usr/local/bundle/gems/kaminari-core-1.2.1/lib/generators/kaminari/views_generator.rb:117:in `get_files_in_master' from /usr/local/bundle/gems/kaminari-core-1.2.1/lib/generators/kaminari/views_generator.rb:41:in `themes' from /usr/local/bundle/gems/kaminari-core-1.2.1/lib/generators/kaminari/views_generator.rb:30:in `copy_or_fetch' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/command.rb:27:in `run' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/invocation.rb:134:in `block in invoke_all' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/invocation.rb:134:in `each' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/invocation.rb:134:in `map' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/invocation.rb:134:in `invoke_all' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/group.rb:232:in `dispatch' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/base.rb:485:in `start' from /usr/local/bundle/gems/railties-6.1.3.1/lib/rails/generators.rb:275:in `invoke' from /usr/local/bundle/gems/railties-6.1.3.1/lib/rails/commands/generate/generate_command.rb:26:in `perform' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/command.rb:27:in `run' from /usr/local/bundle/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command' from /usr/local/bundle/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch' from /usr/local/bundle/gems/railties-6.1.3.1/lib/rails/command/base.rb:69:in `perform' from /usr/local/bundle/gems/railties-6.1.3.1/lib/rails/command.rb:50:in `invoke' from /usr/local/bundle/gems/railties-6.1.3.1/lib/rails/commands.rb:18:in `<main>' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require' from /usr/local/bundle/gems/zeitwerk-2.4.2/lib/zeitwerk/kernel.rb:34:in `require' from /locat/bin/rails:5:in `<main>' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:59:in `load' from /usr/local/bundle/gems/bootsnap-1.7.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:59:in `load' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/commands/rails.rb:6:in `call' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/command_wrapper.rb:38:in `call' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/application.rb:220:in `block in serve' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:10:in `block in fork' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:10:in `block in fork' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:8:in `fork' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:8:in `fork' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:26:in `fork' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:8:in `fork' from /usr/local/bundle/gems/activesupport-6.1.3.1/lib/active_support/fork_tracker.rb:26:in `fork' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/application.rb:180:in `serve' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/application.rb:145:in `block in run' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/application.rb:139:in `loop' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/application.rb:139:in `run' from /usr/local/bundle/gems/spring-2.1.1/lib/spring/application/boot.rb:19:in `<top (required)>' from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from <internal:/usr/local/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb>:85:in `require' from -e:1:in `<main>' ERROR: 1 kaminari導入後に、bootstrap4のページネーションのデザインに合わせたビューファイルを上記のコマンドで実行したところエラーが発生しデザインを適用できない状態になりました。 こちらの記事を参考にしたところ、既にrequire 'open-uri'は記述されていたためエラー解決できませんでした。 解決方法 こちらの記事を参考にしたところ、 gem 'kaminari'を gem 'kaminari', git: 'https://github.com/kaminari/kaminari' に修正した後にで解決できたと記載されていました。 gemfileを修正後にbundle installを行い、再度コマンドを実行したところbootstrapが適用できました。 % docker-compose run web rails g kaminari:views bootstrap4 Creating locat_web_run ... done Running via Spring preloader in process 29 downloading app/views/kaminari/_first_page.html.erb from kaminari_themes... create app/views/kaminari/_first_page.html.erb downloading app/views/kaminari/_gap.html.erb from kaminari_themes... create app/views/kaminari/_gap.html.erb downloading app/views/kaminari/_last_page.html.erb from kaminari_themes... create app/views/kaminari/_last_page.html.erb downloading app/views/kaminari/_next_page.html.erb from kaminari_themes... create app/views/kaminari/_next_page.html.erb downloading app/views/kaminari/_page.html.erb from kaminari_themes... create app/views/kaminari/_page.html.erb downloading app/views/kaminari/_paginator.html.erb from kaminari_themes... create app/views/kaminari/_paginator.html.erb downloading app/views/kaminari/_prev_page.html.erb from kaminari_themes... create app/views/kaminari/_prev_page.html.erb 同じようなエラーに遭遇している方の参考になれば幸いです。 　開発環境 rubymine ruby(3.0.1) Ruby on rails (6.1.3.1) Docker (20.10.7)

ローカルでdocker-composeを使って構築していた環境を共用環境に構築しようとしたらNginxでtemplateが効かなくなったので、備忘録としてメモしておきます 設定 詳細は省略します。 docker-compose.yml proxy: image: nginx container_name: proxy volumes: - ./nginx/dev.conf.template:/etc/nginx/templates/default.conf.template ports: - 80:80 environment: - SERVER_PORT=3000 - LISTEN_PORT=80 nginx/dev.conf.template server { listen ${LISTEN_PORT}; server_name localhost; location / { proxy_pass http://localhost:${SERVER_PORT}/; } } 結論 nginxのDockerイメージを1.20にする 調査内容 docker exec -it proxy shでコンテナ内に入ってtemplateファイルを確認しましたがちゃんとコピーされていました。 ローカルと共用環境でdocker imagesでイメージのバージョンを確認したところ、両方ともlatestでしたがCREATEDの日付が異なっていました。 DockerHubでバージョンを確認したところ、ローカル環境構築のlatestは1.20で共用環境構築時のlatestは1.21のようでした。 そこで、試しにNginxのDockerイメージを1.20にしてみたところちゃんとtemplateに従ってリバプロしてくれるようになりました。 docker-compose.yml proxy: image: nginx:1.20 真の原因は不明ですが、いったんこれで回避することにしました DockerHubの説明を見るとtemplate自体が1.19で新しく追加された機能みたいなのでまた不安定なのかもしれないですね。 Using environment variables in nginx configuration (new in 1.19) Out-of-the-box, nginx doesn't support environment variables inside most configuration blocks. But this image has a function, which will extract environment variables before nginx starts. Here is an example using docker-compose.yml: web: image: nginx volumes: - ./templates:/etc/nginx/templates ports: - "8080:80" environment: - NGINX_HOST=foobar.com - NGINX_PORT=80 By default, this function reads template files in /etc/nginx/templates/*.template and outputs the result of executing envsubst to /etc/nginx/conf.d. So if you place templates/default.conf.template file, which contains variable references like this: listen ${NGINX_PORT}; outputs to /etc/nginx/conf.d/default.conf like this: listen 80; This behavior can be changed via the following environment variables: NGINX_ENVSUBST_TEMPLATE_DIR A directory which contains template files (default: /etc/nginx/templates) When this directory doesn't exist, this function will do nothing about template processing. NGINX_ENVSUBST_TEMPLATE_SUFFIX A suffix of template files (default: .template) This function only processes the files whose name ends with this suffix. NGINX_ENVSUBST_OUTPUT_DIR A directory where the result of executing envsubst is output (default: /etc/nginx/conf.d) The output filename is the template filename with the suffix removed. ex.) /etc/nginx/templates/default.conf.template will be output with the filename /etc/nginx/conf.d/default.conf. This directory must be writable by the user running a container. 引用：https://hub.docker.com/_/nginx

Docker-compose.ymlについて Docker-composeは、複数のdockerイメージをビルドしてコンテナを作成できる。 コマンド一つで複数のコンテナを起動できる。 Docker-compose.ymlといいファイルに、コンテナの中身をサービスとして定義する。dockerイメージなどを指定する感じ。 詳しい中身 実際何を定義してるの？って話 version: Dockerエンジンが1.13.1+以上がverison3.0に対応してる。 バージョン指定しない場合は、レガシーフォーマット である1.0となる マイナーバージョンを指定しないversion: '3'とかの場合はマイナーバージョン0version: '3.0'になる。 3と2で結構違うぽい。特別な理由がなければ3を使うので良いと思われる。 対応表 https://docs.docker.com/compose/compose-file/ service: 起動するコンテナに相当する。 サービス名は自分で決めて良い。 例えば公式から拝借した↓の定義だと、dbとなっている部分は自分で決めることができる。 version: "3.9" services: db: image: postgres:9.4 volumes: - db-data:/var/lib/postgresql/data networks: - backend deploy: placement: max_replicas_per_node: 1 constraints: - "node.role==manager" image: Dockerイメージを使用する場合はここでイメージを指定する。 resart： 再起動設定 デフォルトはno コンテナが終了してても再起動をするかどうか 英語↓ 日本語↓ depends_on: サービス間(コンテナ間)の依存関係を記述できる。 コンテナを起動したときは 依存されているやつ → 依存しているやつ 終了する時は 依存しているやつ → 依存されてるやつ の順番になる links: コンテナ同士を連携させる。でもこれを使うのは古い。 docker-composeを使うと、自動的に連携されているので記述は不要。 ports: ホストとコンテナのポートを対応づける。 ホスト側の値がキーで、コンテナ側の値はバリューになる。 volumes: コンテナ内にデータをおいてもコンテナを破棄すると消えてしまうので、コンテナの外(ボリューム)におく。 やり方は、主に２種類ある。 バインドマウント https://matsuand.github.io/docs.docker.jp.onthefly/storage/bind-mounts/ ホスト側のディレクトリをコンテナ内のディレクトリと共有する。 ボリュームと違って既存のディレクトリをマウントするので、ホストマシンのファイルシステムに依存することになる。従って、ボリュームを使うことが推奨されている。 ボリューム https://matsuand.github.io/docs.docker.jp.onthefly/storage/volumes/ ホスト上(macのdockerはVMで動いてるのでVM)に新規でディレクトリが作成されて、保存領域を確保してくれる。Linux なら /var/lib/docker/volumes/以下になる。 名前付きボリュームと匿名ボリュームがあり、名前付きの場合は Docker ホスト内で名前解決できるのでアクセスしやすい。匿名ボリュームは適当にハッシュ値が振られる。他のプロセスからは触ることができないので安全。基本はこれを使うのがよい。 docker volume lsでボリューム一覧を見ることができる。実態を見るには↓がわかりやすかった。 [Docker for Mac] Docker Volumeの実態がどこにあるのか、探してみた｜w0o0ps｜note マウントオプション マウントオプションというものがある。 https://docs.docker.jp/docker-for-mac/osxfs-caching.html](https://docs.docker.jp/docker-for-mac/osxfs-caching.html consistent ：完全な一貫性（常にホストとコンテナが完全に同じ表示） cached ：ホストの表示が信頼できる（ホスト上の更新がコンテナ上に反映するまで、遅延が発生するのを許容） delegated ：コンテナの表示が信頼できる（コンテナ上の更新がホスト上に反映するまで、遅延が発生するのを許容） environment: 環境変数。ホストじゃなくてコンテナに割り当てられる。 以下、pypmyadminとMySQLを使ったので個人的なまとめ pypmyadminの環境変数 PMA_ARBITRARY：1にすると、任意のサーバーに接続できる。 PMA_HOST：MySQLのホスト(サービス)の名前 PMA_USER and PMA_PASSWORD：ユーザー名とパスワード PMA_PORT：MySQLのポートを指定する MySQLの環境変数 MYSQL_ROOT_PASSWORD：rootアカウントのパスワード MYSQL_DATABASE：データベース名 Build: content: dockerfileがあるディレクトリ dockerfile: dockerfileの名前 args: dockerfile内で使用する環境変数 参考 https://blog1.mammb.com/entry/2020/05/19/090000 https://qiita.com/aki_55p/items/63c47214cab7bcb027e0 https://qiita.com/gounx2/items/23b0dc8b8b95cc629f32 https://qiita.com/nacika_ins/items/cf8ceb20711bd077f770

全体の流れ VPC内でインスタンスを作成しインターネットからアクセスできるようにする(手順は割愛。インターネットゲートウェイとかで調べたら出てくると思います) springbootプロジェクトをインスタンスに入れる(ない場合はInitialierなどで適当に作る。参考1、参考2) DockerFileを作ってimageをbuildする 作ったimageを元にコンテナを起動 publicipアドレスからアクセス可能に DockerFileを作る FROM openjdk:11-jre-slim WORKDIR /app COPY ./build/libs/${jarname}.jar . ENTRYPOINT ["java", "-jar", "${jarname}.jar"] imageビルド $ docker build --build-arg JAR_FILE=build/libs/\*.jar -t ${username}/${repos} . コンテナ実行 $ docker run -p 8080:8080 ${username}/${repos} springbootアプリケーションが起動する $ docker run -p 8080:8080 name/repos . ____ _ __ _ _ /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ \\/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_\__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v2.5.4)

概要 Ubuntuで新規環境構築した際、自分がインストールする物をまとめてみました 以下が本記事でインストールする物 linuxbrew Docker GitHub CLI VSCode 拡張機能、設定 内容 GitHubCLI Linux環境でのインストール方法 USER_NAME=hoge sudo git clone https://github.com/Homebrew/brew ~/.linuxbrew/Homebrew && sudo mkdir ~/.linuxbrew/bin && sudo ln -s ~/.linuxbrew/Homebrew/bin/brew ~/.linuxbrew/bin && echo 'eval $(~/.linuxbrew/bin/brew shellenv)' >> ~/.bashrc # Linux環境でRootUserでないとsudo brew install gh は権限の関係上できないので、Brewに権限を与える sudo chown -R $(whoami) /home/${USER_NAME}/.linuxbrew/ # brew の元のRubyかなにかがgcc を使っているのかローカルにgccをインストールする必要あり sudo apt install -y gcc brew install gh gh version Docker 最新版のDockerインストール Ubuntu 20.04 LTSに最新のdocker-composeをインストールする方法 | LFI # 最新バージョン番号の取得 COMPOSE_VERSION=`git ls-remote https://github.com/docker/compose | grep refs/tags | grep -oE "[0-9]+\.[0-9][0-9]+\.[0-9]+$" | sort --version-sort | tail -n 1` # 最新バージョンのダウンロード sudo curl -L https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose # 実行可能モードを設定 sudo chmod +x /usr/local/bin/docker-compose # Bash自動補完スクリプトのダウンロード sudo curl -L https://raw.githubusercontent.com/docker/compose/${COMPOSE_VERSION}/contrib/completion/bash/docker-compose -o /etc/bash_completion.d/docker-compose aptで入るdocker-composeはバージョンが古く3.3までしか使えないので注意 apt install -y docker.io sudo apt install -y docker-compose VSCode 同じアカウント間で同期する場合、Githubアカウントの認証からGistを生成する機能を使うのが手っ取り早い 以下は違うアカウントなどで行う場合 拡張機能の同期 VS Codeの拡張機能一覧をエクスポートするには | Hinemosu 環境の拡張機能一覧の出力 code --list-extensions | xargs -L 1 echo code --install-extension 別の環境で上記コマンドの出力結果を貼り付けて実行すれば拡張機能がインストールされる # 出力例 code --install-extension yzhang.markdown-all-in-one 個人開発環境で使用している一覧 # code --install-extension WSL: Ubuntu-20.04 にインストールされている拡張機能: code --install-extension eamodio.gitlens code --install-extension GraphQL.vscode-graphql code --install-extension ms-azuretools.vscode-docker code --install-extension MS-CEINTL.vscode-language-pack-ja code --install-extension ms-kubernetes-tools.vscode-kubernetes-tools code --install-extension mushan.vscode-paste-image code --install-extension redhat.vscode-yaml code --install-extension shd101wyy.markdown-preview-enhanced code --install-extension yzane.markdown-pdf code --install-extension yzhang.markdown-all-in-one 設定の同期 最低限行っている設定。主にMarkdown関連。その他はDocker開発環境によって適切な設定を行っている setting.json { "editor.tabSize": 2, "[markdown]": { "editor.wordWrap": "on", "editor.quickSuggestions": false, "editor.formatOnSave": true, "editor.defaultFormatter": "yzhang.markdown-all-in-one", }, } git sudo chown -R $(whoami) /usr/bin/git エラー 環境構築する際に発生したエラーとその対策 W: be careful as root. Don't run this as root! rootユーザーを普段使いしている環境でおきたエラー。Brewは親切なのでRootユーザー環境で実行できないような仕組みにしてある 対策としてはrootではないユーザーで実行するようにすること rootとして自作を実行することは非常に危険であり、サポートされなくなりました。 -コドログ 参考資料 LinuxBrew FAQ — Homebrew Documentation Homebrew on Linux — Homebrew Documentation

はじめに ローカル環境を汚さずに手軽にTerraformとAWS CLIを利用したい... 本記事では、TerraformとAWS CLIの公式Dockerイメージを用いて、Dockerコンテナ上でAWS環境用のTerraformとAWS CLIを実行する方法をご紹介します。 Terraformとは、AWSなどの様々なクラウドサービスの環境を、Terraform用の設定ファイルを元に自動的に構築するツールです。AWSのWeb上のコンソール画面から環境を作成するのではなく、Terraform用の設定ファイルから環境を作成、変更、削除することができ大変便利です。 AWS CLIとは、AWSの操作をコマンドライン上から行えるツールです。 前提条件 AWSアカウントを持っている Dockerがインストールされている Windowsの場合: Docker Desktop for Windows Macの場合: Docker Desktop for Mac TerraformとAWS CLIの環境構築 ファイル構成 下記の構成でファイルを作成します。 /docker-compose.yml version: '3' services: terraform: image: hashicorp/terraform:1.0.6 env_file: - ./.aws/aws.env volumes: - ./terraform:/terraform working_dir: /terraform entrypoint: sh tty: true aws-cli: image: amazon/aws-cli:2.2.36 env_file: - ./.aws/aws.env volumes: - ./aws-cli:/aws-cli working_dir: /aws-cli entrypoint: sh tty: true /.gitignore .terraform *.tfstate *.tfstate.* aws.env /.aws/aws.env.default AWS_ACCESS_KEY_ID= AWS_SECRET_ACCESS_KEY= AWS_REGION=ap-northeast-1 AWS_DEFAULT_REGION=ap-northeast-1 /terraform/test/main.tf # プロバイダ provider "aws" { region = "ap-northeast-1" } # VPC resource "aws_vpc" "test-vpc" { cidr_block = "10.1.0.0/16" instance_tenancy = "default" enable_dns_support = true enable_dns_hostnames = true tags = { Name = "test-vpc" } } IAMのアクセスキーとシークレットアクセスキーを設定 自分のAWSアカウントにログインし、下記のページからIAMのアクセスキーとシークレットアクセスキーを作成します。 AWSのIAMアクセスキーの作成画面 下記の環境変数ファイルをコピーして、IAMのアクセスキーとシークレットアクセスキーを設定します。 コピー元: /.aws/aws.env.default コピー先: /.aws/aws.env /.aws/aws.env の追記例: AWS_ACCESS_KEY_ID=XXXXXXXXXXXXXX AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXX 不正アクセスの原因になるため、/.aws/aws.env はGit等にプッシュしないようご注意ください。 /.gitignore で/.aws/aws.envをGit対象外にしています。 Terraformを実行 下記のコマンドを実行してTerraformを実行します。 今回はサンプルとしてtest-vpcの名前でVPCを作成します。 実行対象ファイル: /terraform/test/main.tf > docker-compose up -d > docker-compose exec terraform sh # cd /terraform/test/ # terraform init (Terraformの初期化を行う。初回に1回だけ実行) # terraform plan (AWSの変更内容を確認します。まだAWSには反映されません) # terraform apply (実際にAWS上にtest-vpcのVPCを作成します。 「Enter a value:」と表示されるので「yes」を入力します) # terraform destroy (AWS上のtest-vpcのVPCを削除します。 「Enter a value:」と表示されるので「yes」を入力します) # exit > docker-compose down (もうDockerコンテナを利用しない場合) AWS CLIを実行 下記のコマンドを実行してAWS CLIを実行します。 今回はサンプルとしてEC2のリージョン一覧を表示します。 > docker-compose up -d > docker-compose exec aws-cli sh # aws ec2 describe-regions (EC2のリージョン一覧を表示。エラーになる場合は /.aws/aws.env の内容が間違っている。q を入力すると終了) # exit > docker-compose down (もうDockerコンテナを利用しない場合) まとめ Dockerコンテナ上でTerraformとAWS CLIを使うことにより、ローカル環境を汚さずに手軽にTerraformとAWS CLIを利用することができました。 このファイル構成でgit等でソース管理することにより、新しいプロジェクトメンバーが増えた際に、Gitのクローンとdocker-compose up -dの実行だけで、プロジェクト全体で同じバージョンのTerraformとAWS CLIのローカル環境を素早く作成することができます。

AWSの環境構築をTerraformで行う際に、環境依存やバージョン管理を考慮する必要があります。 その管理を簡略化するため、Dockerを用いて環境をコンテナ化します。 また、コンテナ内のTerraformでECRの操作を行うため、DooD(Docker outsude of Docker)という仕組みでコンテナ内からDockerの機能が利用できるようにします。 ターゲット TerraforomまたはAWS CLI環境をコンテナ化したい Dockerコンテナ内でDockerを使いたい Terraformを使う方法 TerraformをDockerコンテナで使用する方法として公式イメージを使用します。 バージョンを固定したい方は、latestを置き換えてください。 Dockerfile FROM hashicorp/terraform:latest HashiCorp公式のDocker Hubを参照することで、golang:alpineイメージにセットアップする方法も分かります。 AWS CLIを使う方法 AWS CLIを使用するには、glibcのインストールも必要です。 バージョンはENV GLIBC_VER=で指定してください。(例として2021/9/9時点で最新の2.34-r0を指定します。) 今回はAlpine Linuxにインストールする想定で作成しています。また、AWS CLIはv2をインストールします。 Dockerfile FROM golang:alpine # install glibc ENV GLIBC_VER=2.34-r0 RUN apk --no-cache add binutils curl && \ curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk && \ apk add --no-cache glibc-${GLIBC_VER}.apk glibc-bin-${GLIBC_VER}.apk # install awscliv2 RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && \ unzip -q awscliv2.zip && \ aws/install DooDをするための方法 DooDはDocker outside of Dockerの略です。 ホストのDockerソケット/var/run/docker.sockをマウントすることで、Dockerコンテナ内からもDockerの機能を使用できるようにすることです。 注意としては、ホストと同じDockerデーモンを使用するためイメージなども共有されます。 Alpine Linuxなど、Dockerコマンドがない場合はインストールが必要です。 Dockerfile FROM golang:alpine # install Docker CLI RUN apk update && \ apk add --no-cache docker-cli && \ apk add --no-cache docker-compose Dockerfileを使用してコンテナを起動する際は、以下のように-vオプションでソケットをマウントします。 docker run -it -v /var/run/docker.sock:/var/run/docker.sock <IMAGE_ID> /bin/ash おすすめの方法は、docker-compose.ymlを作成してvolumesで予め記述することです。 docker-compose.yml version: '3' services: dood: container_name: dood-container build: . volumes: - /var/run/docker.sock:/var/run/docker.sock entrypoint: ash tty: true docker-compose build --no-cache docker-compose up -d docker-compose exec dood /bin/ash Terraform+AWS CLI+DooDをする これまで説明した内容をふまえて、Terraform,AWS CLI,Dockerコマンドが使用できるDockerfileを作成します。 Dockerfile FROM hashicorp/terraform:latest # install Docker CLI RUN apk update && \ apk add --no-cache docker-cli && \ apk add --no-cache docker-compose # install glibc ENV GLIBC_VER=2.34-r0 RUN apk --no-cache add binutils curl && \ curl -sL https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub -o /etc/apk/keys/sgerrand.rsa.pub && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-${GLIBC_VER}.apk && \ curl -sLO https://github.com/sgerrand/alpine-pkg-glibc/releases/download/${GLIBC_VER}/glibc-bin-${GLIBC_VER}.apk && \ apk add --no-cache glibc-${GLIBC_VER}.apk glibc-bin-${GLIBC_VER}.apk # install awscliv2 RUN curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip && \ unzip -q awscliv2.zip && \ aws/install docker-compose.ymlで作成したDcokerfileのフォルダパスを指定します。(例では同じ階層にある想定です。) また、DooDのためにvolumesで/var/run/docker.sockをマウントします。 docker-compose.yml version: '3' services: terraform: container_name: terraform-container build: . volumes: - /var/run/docker.sock:/var/run/docker.sock entrypoint: ash tty: true コンテナを立ち上げてみましょう。 docker-compose build --no-cache docker-compose up -d docker-compose exec terraform /bin/ash execで中に入れたら、各ツールが使えるか確かめましょう。 例としてバージョンを確認してみます。 Terraformバージョン確認 terraform -v Terraform v1.0.6 Dockerバージョン確認 docker -v Docker version 20.10.7, build f0df35096d5f5e6b559b42c7fde6c65a2909f7c5 AWSCLIバージョン確認 aws --version aws-cli/2.2.36 Python/3.8.8 Linux/5.10.16.3-microsoft-standard-WSL2 exe/x86_64.alpine.3 prompt/off さいごに Alpine Linuxコンテナをベースに、TerraformやAWS CLIを使用する方法を説明しました。 DooDを組み合わせることで、TerraformでAWSのコンテナ関連サービスを利用する際に役立つのではないかと思いますので、ぜひ利用して頂ければ幸いです。 参考 DooD(Docker outside of Docker)でボリュームマウント DockerでTerraformを使う Alpine ベースのコンテナイメージで AWS CLI v2 を使う

AWS環境構築について 参考 学習 Dockerとは docker, docker-compose, docker compose, それぞれ何？ Dockerfile docker-compose.ymlは何をしているのか。 ECR,ECSについて つまり・・・？ context とは 参考 Docker compose ことはじめハンズオン ecsでLaravelのトップページ表示まで 今から追いつくDocker講座！AWS ECSとFargateで目指せコンテナマスター！〜シリーズ1回目〜 自己紹介 組み込みエンジニア ⇨ UnityでMR/VR制作 ⇨ モーショングラフィック等の映像制作。AWS?なにそれ、美味しいの？ WEBのフロントエンドは少し、バックエンドはさっぱり。 今回はWEBシステムを構築することになったので、その時に勉強したことをまとめます。 学習 ローカルで作成したLaravel環境をECSにデプロイするにあたって、色んな所を調べてもそれぞれやっている内容や、Dockerfileの中身が違っていたりした為かなり苦戦した。 そのため一つ一つ動きや考え方を再学習したので、ここに記録を残す。 ※初心者がネットを漁ってつけた知識ですので、解釈に齟齬があるかもしれません。間違っていたらご指摘頂けるとありがたいです。 Dockerとは Dockerについては参考のYoutubeが非常にわかりやすかった。 自分が作成したい環境を一発で立ち上げることのできるパソコンを作る仕組みみたいなイメージだと思う。 Docker環境を作成しておけば、それぞれを起動するだけでどこでもアプリケーションが実行可能になる。 docker, docker-compose, docker compose, それぞれ何？ それぞれターミナルで実行可能なコマンドだが、人によって使っているものが違う。 docker は Dockerfile に対してごにょごにょする機能。 docker は単一のコンテナに対してしか操作できないため、複数のコンテナを同時に管理できる仕組みが出来た それが docker-compose で docker-compose.yml ファイルを用いて管理する。 そのdocker-compose の機能を docker に互換性を持たして docker-compose と（ほぼ）同等の命令を出せるのが docker compose　である。 Dockerfile docker-compose.ymlは何をしているのか。 これらのファイルはそれぞれコンテナのイメージの情報を記載している。 イメージ的にはPCのスペック表みたいなイメージ？ FROMで動作する環境を定義し、他でアプリをインストールしたり、環境変数を定義したり、開放するポート番号を定義したり、ボリュームマウントを定義したり... また docker-compose.yml に記載されている image では、他所（指定しなければdocker hubから）イメージを持ってきて即座に環境構築ができる。 ここで持ってくるイメージと、docker compose build で出来るイメージのせいでDockerの動きがうまくイメージできませんでした。(最後のイメージはinterpretationのイメージです。他でも使ってるのでごっちゃなったらすいません。) 例えるなら、誰かが作成したPCを購入し、自分でSSDやRAMを増設したり、GPUを入れ替えて使う、みたいなイメージ。 ECR,ECSについて 詳しい説明は省くが、Docker環境を実行する場所のイメージ。 ローカルでビルドしたイメージデータをECRへプッシュし、ECSでそのデータをデプロイし、Fargateで実行します。 FargateはECSでコンテナを展開するための方式みたいなもので、他にはEC2があります。 ECRが作ったパソコンパーツを置く場所で、ECSはPCを組み立て電源をつくてくれる人で、Fargateは電源見たいなものです（ちょっと無理があるか） ここで大事なのが、ECSは Dockerfile を ビルドして実行してくれるわけですが、DockerHubにあげられているイメージを使用すればECRを介さずにECSでDockerを実行できることです。 例えばWordpressの環境等の出来合いのイメージを記載した Dockerfile をECSで実行すればそのままWordpressの環境が作れます。 逆に言うと、自分が作成したイメージをECRへプッシュしECSでデプロイするには、ECSにイメージの場所を伝えないと行けないんですね。 ECRプッシュコマンド表示では docker を用いてタグ付けしているのがその部分なのですが、 docker-compose を用いた場合は同じやり方では出来ません。 そこで image にそのタグ付けをすることで実行することができます。 image: xxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/[リポジトリ]:latest デプロイする時も、ここからイメージを取得し展開してくれます。 これが初めは理解できずに苦労しました。 つまり・・・？ ローカルで Docker image を作成 docker, docker-compose, docker compose　で build 作成した image を ECR へ push ECS で Dockerfile をビルドして実行 up context とは ファイルをどこで実行するか、見たいなイメージでいいと思う。 例えば上記1,2はローカルで行うが、3はECSで行うのでコンテキストを切り替える必要がある。 また、ymlファイルの build: に度々記載されている context は Dockerfile をどこで実行するかと言うこと。 例えば bild: ./php だと ./php 上で Dockerfile を実行してくれるが、Dockerfile で実行されるパスは ./php がルートになる。 build: cntext: . ockerfile: ./php/Dockerfile だと ./ をルートとして Dockerfile を実行している。 これの何がいいのかと言うと、 Dockerfile では上位のフォルダにアクセスすることができないからです。 COPY ../../app /work # これはNG COPY ./app /work # これはOK Docker単体で動かす場合は -f でDockerファイルを指定してもいいそうです。 終わりに とりあえずこんなところで、なんとなくAWS上でサービスを動かす仕組みがわかってきた気がしました。 巷ではいろんなやり方が書かれているけど具体的な説明は少ない or 分からないで大苦戦・・・ まだネットワーク周りがさっぱり分からないので、その辺りも学習していきます。

docker-composeでghostのローカル開発環境を立ち上げるまでの手順を簡単に書いていきたいと思います。 ■なんでやろうと思ったか ghostを使ってJAMStackなポートフォリオ兼ブログサイトを作りたいと思ったから。 ともかくghostの環境構築にはDockerが良いらしいということで、よくわからないけどやってみることにしました。（GhostのイメージはDockerhubで公式配布されてます） 私はWindowsユーザーなのでWSL2のセットアップからスタートしたわけですが、多少苦戦しながらも5時間ぐらいでローカル環境の立ち上げに成功しました！Dockerすげえよ！！！（今更） ■実行環境 マシン : Win10 home 実行OS: Ubuntu 20.04 LTS(WSL2) Terminal : Windows Terminal Docker Desktop(ver 20.10.8) 1.プロジェクト用の空ディレクトリを作成 Windows TerminalからUbuntu開いて、そこで作業していきます。 まずは空ディレクトリを作成し、cdコマンドでディレクトリに移動しておきます。 ubuntu-20.04のターミナル ~/$ mkdir docker-compose-ghost（ディレクトリ名はよしなに） ~/$ cd docker-compose-ghost ~/docker-compose-ghost$ 2.docker-compose.ymlを作る touchコマンドでdocker-compose.ymlファイル作成。 ymlファイル作成 $ touch docker-compose.yml ファイルが作成されたら、viコマンドでdocker.compose.ymlを開き、Dockerイメージの情報やコンテナを起動するための情報を記述していきます。 ちなみにvscodeユーザーなら、"code ."と叩けばすぐにvscode上で編集を始めることもできます。どちらにせよ、編集できればおkなのです。 vimで編集をはじめる $ vi docker-compose.yml もしくは、 vscodeにワープ！ $ code . 3.docker-compose.ymlファイルを編集 今回僕は自前でymlファイルを書いたわけではありません。というか書けない。。 ということで、DockerhubにあるGhost公式のリファレンスページで紹介されている記述例をほぼそのまま拝借しました。完成したdocker-compose.ymlファイルはこちら。 「ghost」と「db」、2つのコンテナを作成しています。Volumeとかは作ってないです。 docker-compose.yml version: '3.1' services: ghost: image: ghost:latest restart: always ports: - 8080:2368 environment: # see https://ghost.org/docs/config/#configuration-options database__client: mysql database__connection__host: db database__connection__user: root database__connection__password: example database__connection__database: ghost # this url value is just an example, and is likely wrong for your environment! url: http://localhost:8080 # contrary to the default mentioned in the linked documentation, this image defaults to NODE_ENV=production (so development mode needs to be explicitly specified if desired) #NODE_ENV: development db: image: mysql:5.7 restart: always environment: MYSQL_ROOT_PASSWORD: example ほぼそのままと言いましたが、上記の完成ファイルは一点だけ変更を加えています。Dockerhubのページで紹介されている記述では、ghostイメージのバージョン指定が4-alpineとなっていますが、これだとうまくローカル環境にアクセスできませんでした。 最新バージョンを指定するlatestに変更することで問題なくアクセスできたので、ひとまずこのようにしています。 変更した箇所 - image: ghost:4-alpine + image: ghost:latest 4.ghost,mysqlのイメージを入手 今回使用するイメージを入手しておきます。僕はこれを忘れて沼にハマっていましたｗ それぞれのimageをpull $ docker pull ghost $ docker pull mysql 5.docker-compose upする docker-compose upコマンドで、それぞれのイメージ、コンテナを作成します。正直このコマンドが何者なのかはまだよくわかってないです。 $ docker-compose up うまくいけば、こんな感じでダーッとログが走るハズ。 6.localhost:8080にアクセス ブラウザからlocalhost:8080にアクセスしてみましょう。 多少表示が違うかもしれませんが、こんな感じでghostのページに遷移すれば成功です！ 上記画面にアクセス出来たら、URLをlocalhost:8080/ghost/としてghostを追加します、すると管理者画面に遷移できるので、そのまま作業したいのであればサインアップしちゃいましょう。 今回はとりあえずここまで。 さいごに Dockerやdocker-composeのこともよくわかっていない中ではあるものの、何とかGhostのローカル環境を立てることができました。（まだ始まってすらいないけど...） 作業自体大したことではないかもしれませんが、Dockerを使った環境構築は僕にとってかなりの感動体験でした。 ちゃんと理解して使うとなると難しい部分が多そうなので、基本からしっかりとキャッチアップしていかねば。

Rayとは RayはPythonにおける分散並列処理を高速かつシンプルに書けるフレームワークで、既存のコードを並列化することも容易な設計となっています。 Rayを使うことでmultiprocessingなどに比べ簡単にプロセスレベルの並列処理を記述することができます。Rayは2021年9月現在MacOSとLinuxをサポートしています。Windowsのサポートは実験段階であり、開発中です。 ローカル環境を構築する予定でしたが、既知のバグがあるらしく動かなかったので、仕方なくDocker環境を構築します。 環境 macOS Big Sur 11.5.2 docker 20.10.7 python 3.7.7 (dockerコンテナ内) M1MacにDockerDesktopをインストール M1MacにDockerDesktopをインストールするには、上のリンクを踏んでダウンロードする必要があります。 さらに、Rosetta2もインストールしなければならないため、公式ページの指示に従って以下のコマンドをターミナルで叩きます。 Rosetta2 install softwareupdate --install-rosetta これでDockerが使用可能になります。 ちなみに、2021年8月31日にDocker社がDocker Desktopを有料化することを発表したようですね。個人開発なら無料で使えますが、面倒なことになりました。 RayのDocker ImageをPullする DockerHubから公式のImageをローカルにPullします。 docker pull rayproject/ray コンテナ内でjupyter notebookを実行する まず、Docker Imageからコンテナを作成し、中に入ります。 docker run --shm-size=512M -p 8888:8888 -it rayproject/ray 公式ページによると、shm-sizeには512M~2G程度の値を設定するようです。 また、jupyter notebookを使用する関係でポートを公開しています。 コンテナ上のポートとローカルのポートを接続するルールは、-p [ローカルのポート]:[コンテナのポート]　です。 コンテナ内に入ったら、jupyter をインストール後、サーバを立てます。 pip install jupyter jupyter notebook --ip=0.0.0.0 --allow-root Docker上でjupyter notebookを実行する方法は以下を参考にしました。 ブラウザでnotebookにアクセス ローカルPCのブラウザでコンテナで起動したnotebookにアクセスします。 ブラウザに下記URLを打ち込みます。 localhost:8888 するとJupyter Notebookの画面に遷移してPassword or token:と入力が求められます。 入力するためのtokenはコンテナ上でnotebookを起動したときに以下のようなURLが出るのでそこから取得します。 Copy/paste this URL into your browser when you connect for the first time, to login with a token: http://5217807fea51:8888/?token=601c330c097e59cd7b69dcaa6ea336218583a492e4684bde&token=601c330c097e59cd7b69dcaa6ea336218583a492e4684bde 上の場合、601c330c097e59cd7b69dcaa6ea336218583a492e4684bdeをPassword or token:に入力すればいつものnotebookの画面に遷移します。 サンプルコードを動かし動作確認を行う チュートリアルの解説に関しては以下のページが神です。 サンプルコードがエラーなく実行できれば成功です。 import ray import time # ray.init() のように明示的に指定しなかった場合自動的にリソース数が決定されます ray.init(num_cpus=4) # 時間計測をより正確にする都合上Rayの起動を少し待つ time.sleep(1) @ray.remote def func(x): time.sleep(5) return x begin_time = time.time() res1, res2 = func.remote(1), func.remote(2) print(ray.get(res1), ray.get(res2)) # 出力: 1 2 # ray.getはreturnをリストで受けとることもできる print(ray.get([res1, res2])) # 出力: [1, 2] end_time = time.time() print(end_time - begin_time) # 5秒ぐらい 実行結果例 1 2 [1, 2] 5.051432132720947 終わりに 標準モジュールのmultiprocessingと比べるとコードが非常に簡単です。まだまだ発展途上のフレームワークですが、いずれ「マルチプロセスといえばRay」というようになっていくでしょう。 なお、コードを速くするという意味では、マルチプロセス化するのは最後の手段です。まずは既存のコードを整理し、充分にリファクタリングしたいところです。

Orthanc を使ってみた 　医療用画像の規格である DICOM をお使いの皆さん、Orthanc ってご存知でしょうか。私も最近知って使ってみたのですが、とても便利ですよね！ 　Orthanc の公式サイトでは「Open-source, lightweight DICOM server.」とうたっています。まさにこの通りで、とても簡単に構築でき、トラブルもなく大変便利に使っています。REST API や Lua 言語によるスクリプトも組めるし、フリーだし、素晴らしいです。数百 Study の MRI を溜め込んでますが、今の所トラブルフリーです。 　この記事は試しに Orthanc を少々使ってみた、個人的備忘録的にまとめてみものです。 参考にした web site 本家：https://www.orthanc-server.com/ 説明書 (Orthanc book)：https://book.orthanc-server.com/ サーバ環境の整備 私の環境 今回使用した環境はこちら * OS: Ubuntu 20.04.2 LTS * Docker version 20.10.8 * Mozilla Firefox 90.0.2 Docker rootless まずはこちらの公式サイトの手順で Docker を整備しました。 https://docs.docker.com/engine/install/ubuntu/ さらに Docker rootless の環境を用意しました。これも公式サイトの手順で OK でした。「Caution: This is experimental function. Please use carefully.」とあるので注意します。 https://docs.docker.jp/engine/security/rootless.html カスタマイズせずに Orthanc を起動してみる Orthanc の公式 Docker は様々な repository があります。 https://hub.docker.com/u/jodogne 今回は公式プラグイン全部のせを使ってみます。 https://hub.docker.com/r/jodogne/orthanc-plugins コマンドはこちら。Port 8042 は http 用です。 $ docker pull jodogne/orthanc-plugins $ docker run --rm -d --name orthanc1 -p 8042:8042 \ jodogne/orthanc-plugins $ docker ps -a などで無事に動作したことが確認できれば、http://localhost:8042/ にアクセスしてみましょう。ID と Password の入力を求められますので、それぞれ「orthanc」、「orthanc」と入力します。すると、このような Orthanc Explorer の画面が見えましたか？ この Orthanc Explorer 画面の操作は非常に簡単でわかりやすいです。手元にデータが有れば、「Upload」でデータをアップロードしたり、「Do lookup」で保存されたデータを確認したり、画像を見たり、色々やってみましょう。 一通り楽しんだら、コンテナを止めましょう。 $ docker stop orthanc1 Orthanc のカスタマイズ Orthanc の設定をカスタマイズをしてみましょう。 "orthanc.json" が設定ファイルです。デフォルトの設定ファイルを "~/Orthanc/Config1/" に保存してみましょう。 $ mkdir ~/Orthanc $ mkdir ~/Orthanc/Config1 $ docker pull jodogne/orthanc-plugins:1.9.6 $ docker run --rm --entrypoint=cat \ jodogne/orthanc-plugins:1.9.6 \ /etc/orthanc/orthanc.json > ~/Orthanc/Config1/orthanc.json これで "~/Orthanc/Config1/orthanc.json" が生成されました。このファイルを編集しましょう。 変更部分を抜粋すると、この様になりました。 orthanc.json // HTTP port 番号の変更 (line 81) "HttpPort" : 50010, // AET の変更 (line 119) "DicomAet" : "ORTHANC1", // DICOM port 番号の変更 (line 126) "DicomPort" : 60010, // すべての SOP class を受け入れる (line 160) "UnknownSopClassAccepted" : true, // ID, Password を入力させるための "//" の削除 (line 229) "RegisteredUsers" : { "alice" : "alicePassword" }, // 末尾に "," の追加 (line 826) "SynchronousZipStream" : true, // PostgreSQL を使うための設定 (line 827) "PostgreSQL":{ "EnableIndex":true, "EnableStorage":true, "Host":"192.168.10.12", "Port":5432, "Database":"orthanc", "Username":"otpostgres", "Password":"otpassword" } 設定ファイルに文法的な問題がないか確認します。 $ cat ~/Orthanc/Config1/orthanc.json |json_verify -c JSON is valid 　Orthanc のデフォルトでは、データベースとして SQLite を使用していますが、性能やスケーラビリティの面から他のデータベースの利用が推奨されています。今回は postgreSQL を使用することにします。設定ファイルでは、最後に記述されている部分がそれに対応します。 　コンテナやサーバ再起動後にもデータが消失しないように、 PostgreSQL 用のディレクトリを作成します。DB はここに保管されることになります。 $ mkdir ~/Orthanc/DB1/ PostgreSQL のコンテナを起動し、Database を作成します。このとき先ほど作成したディレクトリを指定します。また、 Docker の network として "orthanc_nw" も作成します。 $ docker pull postgres:13.3 $ docker network create --subnet=192.168.10.0/24 orthanc_nw $ docker run -d --name orthanc-postgres1 \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ -v /home/hogehoge/Orthanc/DB1/:/var/lib/postgresql/data \ -e POSTGRES_USER=otpostgres \ -e POSTGRES_PASSWORD=otpassword \ --net=orthanc_nw --ip=192.168.10.12 \ postgres:13.3 $ docker run -it --link orthanc-postgres1:postfres \ --net=orthanc_nw --rm postgres:13.3 \ sh -c 'echo "CREATE DATABASE orthanc;" \ |exec psql -h 192.168.10.12 -p 5432 -U otpostgres -h 192.168.10.12' 　このあとPassword for user otpostgres:と表示されるので、設定ファイルで指定した "otpassword" と入力します。 これで Database が生成されました。 　それでは、Orthanc を起動しますが、先の設定ファイルの場所を指定し、タイムゾーンをサーバ環境と同じものを使うようにし、IPアドレスを指定し、詳細なログを吐くように設定します。 $ docker run -d --name orthanc1 \ -p 50010:50010 \ -p 60010:60010 \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ -v /home/hogehoge/Orthanc/Config1/:/etc/orthanc/ \ --net=orthanc_nw --ip=192.168.10.11 \ jodogne/orthanc-plugins:1.9.6 \ --verbose /etc/orthanc Orthanc の コンテナが起動に成功したかどうか $ docker ps -aで確認します。 成功したなら、 http://localhost:50010 にアクセスします。ID と Password の入力を求められますので、それぞれ「alice」、「alicePassword」と入力します。無事起動できたでしょうか。 OK ならデータを Push してみます。今回は、dcm4che/dcm4che-tools　を使用します。 $ docker pull dcm4che/dcm4che-tools:5.25.0 $ docker run --rm --net=orthanc_nw --ip=192.168.10.100 \ dcm4che/dcm4che-tools:5.25.0 \ storescu -bDCM4CHEE \ -cORTHANC1@192.168.10.11:60010 \ /opt dmc4che/etc/testdata/dicom ブラウザの "Do lookup" をクリックすると送ったデータが見えるはずです。図のように "DOE^J1 - LEFT WRIST" が見えればOKです。 コンテナを止めた後に再度起動して、送ったデータが保存されているか確認します。 $ docker stop orthanc1 orthanc-postgres1 $ docker rm orthanc1 orthanc-postgres1 $ docker run -d --name orthanc-postgres1 \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ -v /home/hogehoge/Orthanc/DB1/:/var/lib/postgresql/data \ -e POSTGRES_USER=otpostgres \ -e POSTGRES_PASSWORD=otpassword \ --net=orthanc_nw --ip=192.168.10.12 \ postgres:13.3 $ docker run -d --name orthanc1 \ -p 50010:50010 \ -p 60010:60010 \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ -v /home/hogehoge/Orthanc/Config1/:/etc/orthanc/ \ --net=orthanc_nw --ip=192.168.10.11 \ jodogne/orthanc-plugins:1.9.6 \ --verbose /etc/orthanc 　http://localhost:50010 にアクセスして "Do lookup" をクリックします。 先程同様、 " DOE^J1 - LEFT WRIST" が見えていたら成功です。 　これでその1は完走です。大した苦労もなくできてしまいました。素晴らしい。 　実用上は、サーバ再起動後も自動でコンテナが立ち上がってほしいとか、通信する相手を指定しなければならないとか、受信したデータに対して何らかの処理をしたい、といった要望が出て来ることになると思います。そのあたりを簡単に試したので、その2をいつの日かまとめられたらなぁ、と思っています。いつになりますやら。 つづく 追記 その2を書きました。