JPiereをdocker-composeで試してみる JPiere(ジェイピエール)とはオープンソースのERP iDempiereの日本商習慣対応ディストリビューションです。GPLv2ライセンス。無償で使えるERPパッケージのようなので手っ取り早く、ローカルで使うためにdocker-composeで試してみます。 急いでいる人 JPiereサーバのDockerコンテナをビルドして、docker-composeで起動。 githubからDockerfile、docker-compose.ymlなどを取得 git clone https://github.com/madilloar/PRJ_JPiere.git Dockerコンテナのビルド docker build ./ -f DockerJpiere -t jpiere:8.21 ビルドに失敗したときにコンテナに入って原因追及。 docker run -it --user root --name jpiere {コンテナID} bash -p docker-composeで起動　 Corei5 8MB Windows10 WSL2のdocker環境で起動までに10分程度かかる。 docker-compose up -d 起動状況をログ確認 docker logs -f jpiere_idempiere_1 次のようなメッセージが最後に出ていたら起動完了。 略 11:59:41.010 PackInApplicationActivator.processFilePath: *** Creating list from folder migration/i4.1z [93] 11:59:41.011 PackInApplicationActivator.processFilePath: *** Creating list from folder migration/i7.1z [93] 11:59:41.016 AbstractActivator.setSummary: No zip files to process [93] ログに次のようなエラーが出ていても問題なし バージョンエラーメッセージの例 19:02:52.425-----------> DB.isBuildOK: Build Version Error The program assumes build version 8.2.0.202101020630, but database has build version ${env.ADEMPIERE_VERSION} 20080428-1232. This is likely to cause hard to fix errors. Please contact administrator. [1] 次のURLを参考。【iDempiere Lab】サーバ起動時のDBビルドバージョンエラーについて このDB.javaのisBuildOK()メソッド内では、文字列情報を比較("Build DB"の値と"Build Cl"の値を比較)して異なっていたらこのメッセージが出力されるようにしているだけで、実際にデータベースのスキーマ情報を精査しているわけではありません。 バリデーションエラーメッセージの例 java.lang.Exception: Failed to load model validator class jpiere.plugin.groupware.base.JPierePluginGroupwareModelValidator at org.adempiere.base.DefaultModelValidatorFactory.newModelValidatorInstance java.lang.Exception: Failed to load model validator class jpiere.base.plugin.org.adempiere.base.JPiereBankStatementLineModelValidator at org.adempiere.base.DefaultModelValidatorFactory.newModelValidatorInstance(DefaultModelValidatorFactory.java:64) 以下数件。 次のURLを参考。JPiereコンフィギュレーションズの使用上の注意 JPiere ベースプラグインではモデルバリデータを使用しています。モデルバリデータに設定されているクラスが存在しないとエラーになりますので、JPiereベースプラグインを使用しない場合には、使用しないモデルバリデータを非アクティブにする必要があります。AD_ModelValidatorテーブルの下記の名称(Name)のデータをSQLで非アクティブ(IsActive='N')にして下さい。 ログイン 次のURLでログインします。 ユーザとパスワード 参考URL：JPiereへのログイン Dockerコマンドメモ 実行中のコンテナに入る docker exec -it --user root {コンテナ名} bash -p docker-compose 起動、ログ確認、停止、コンテナ終了 docker-compose up -d docker log -f {コンテナ名} docker-compose stop docker-compose down 止まってしまったコンテナに入って原因追及 docker commit {問題のコンテナID} {新たなコンテナ名} docker run --rm -it {新たなコンテナ名} sh はまったところ docker-composeで試す前に、手動でインストールを試そうとしてはまったこと。 shellの改行文字がCRLF OSDN > Find Software > Office/Business > CRM > JPiere > Download File List > Package JPiere Install Package > Release JPiere82 - 20210101からインストール用のzipとPostgreSQLに登録するdmpファイルをダウンロードして、手順に従って、console-setup.shを動かしたのですが、 $ ./console-setup.sh -bash: ./console-setup.sh: /bin/sh^M: bad interpreter: No such file or directory となってしまいました。shellファイルの改行文字がCRLFになっている。 気になってgrepしたら軒並み改行文字がCRLF。手順では、sh console-setup.shとなっているので、改行文字がCRLFでもよいのだけれど、気持ち悪いので、LFに変える。 $ find . -type f -name '*.sh' | xargs file | grep CRLF | awk -F: '{print $1}' | xargs dos2unix 実行可能ファイルの実行権限がついていない $ ./console-setup.sh Setup idempiere Server : not foundup.sh: 4: console-setup.sh: 6: ./idempiere: Permission denied 略 改行文字同様、他の実行可能ファイル、shellに実行権限がついていない。 $ chmod u+x idempiere $ find . -type f -name '*.sh' | xargs chmod u+x JPiereサーバとPostgreSQLサーバをそれぞれを起動してみる 前提 上記DockerJpiereファイルでDockerコンテナを作成済のこと。 JPiereとPostgresqlをつなぐdocker networkを作成 docker network create jpiere_net PostgreSQLサーバを起動 docker run -d --name postgres --net jpiere_net -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres:12 JPiereサーバを起動 docker run -it --name jpiere -p 8080:8080 --net jpiere_net \ -e DB_HOST=postgres \ -e DB_PORT=5432 \ -e DB_NAME=idempiere \ -e DB_USER=adempiere \ -e DB_PASS=adempiere \ -e DB_ADMIN_PASS=postgres \ jpiere:8.21 JPiereサーバとPostgreSQLサーバがネットワークにつながっているか確認 docker network inspect jpiere_net 参考URL https://hub.docker.com/r/idempiereofficial/idempiere https://github.com/idempiere/idempiere-docker https://mebee.info/2020/11/29/post-17806/ https://www.compiere-distribution-lab.net/jpiere-lab/install/jpiere7-1/

概要 やること Dockerを使ってローカル環境に、1分でWordPressを構築する https://zenn.dev/mochiblock/articles/0fc6bd37320080 上記の記事を参考にした。 version: '3' services: db: image: mysql:5.7 volumes: - db_data:/var/lib/mysql restart: always environment: MYSQL_ROOT_PASSWORD: somewordpress MYSQL_DATABASE: wordpress MYSQL_USER: wordpress MYSQL_PASSWORD: wordpress wordpress: depends_on: - db image: wordpress:latest # ドキュメントに書いてある内容に、vlumesの部分だけ追記（任意） volumes: - .:/var/www/html ports: - "8000:80" restart: always environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_USER: wordpress WORDPRESS_DB_PASSWORD: wordpress volumes: db_data: 公式ドキュメントの上記でなかったのは公式ドキュメントだと volumes: - .:/var/www/html がなく、これがないと.phpの反映などをローカルでできない。今回はローカルで開発したいので編集できるようにする。 コマンド docker-compose up 上記コマンド後 ブラウザでhttp://localhost:8000

最近は docker-compose.yaml　で起動することもあって、ターミナルから起動することがあまりなく、ロケール設定とかタイムゾーンを忘れてしまうのでメモっておく 起動する docker run --name postgres -e POSTGRES_PASSWORD=password -e POSTGRES_INITDB_ARGS="--encoding=UTF8 --no-locale" -e TZ=Asia/Tokyo -v postgresdb:/var/lib/postgresql/data -p 5432:5432 -d postgres 確認する # コンテナにアクセスする docker exec -it postgres /bin/bash # PostgreSQL にログインする psql -h localhost -U postgres # locale確認 postgres-# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+---------+-------+----------------------- postgres | postgres | UTF8 | C | C | template0 | postgres | UTF8 | C | C | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | C | C | =c/postgres + | | | | | postgres=CTc/postgres (3 rows) # TimeStamp確認 postgres=# select NOW(); now ------------------------------- 2021-06-05 22:08:55.231972+09 (1 row) # 抜ける \q exit 終わり

社内Wikiに書いていたけど、個人開発でも参考にしたかったので転記しておく。 コンテナ立ち上げたけど Mavenインストールするの忘れた。後からインストールできる？ docker exec -it  --user root [CONTAINER] apt install maven ってコマンド実行すればできるよ。 普通に/bin/bash しても sudo が無いので apt でインストールができない --user root で root実行ができる。 コマンドは /bin/bash  にしなくても 直接 apt を実行すればいいよね。 Volumeについての雑なまとめ Volume は、コンテナ内のディレクトリを永続化するためのもの Volumeを作成するとまずホストPCにVolume用のディレクトリが作られ、コンテナにマウントする 作成されたVolumeは、コンテナを破棄しても削除されない Volumeの指定方法（作成方法） docker run の -v オプション 代表的なのは3パターン 使っていきたいのは、 No.3の Volume名を指定する方法。 -v [ホストのディレクトリパス]:[コンテナのディレクトリパス] -v [コンテナのディレクトリパス] -v [Volume名]:[コンテナのディレクトリパス] No.1 は厳密には、Bind mount と呼ばれる設定を行っている。Bind mountは、ホスト側の既存ディレクトリをそのままコンテナ側にマウントする使い方である。なのでVolumeという概念とはちょっと異なる。（更に最近だと非推奨という話も挙がっていた） このため、Volumeを作成しているのは No.2 と No.3 のみ。この2つの違いは主にVolumeの命名。前者はハッシュ値を名称に割り当てるのに対して、後者は任意の名称を指定できるのでどのコンテナで利用しているVolumeかが分かりやすい。 指定したVolumeが ホスト側のどこに存在するかを知りたい場合は、 docker volume inspection [Volume名] を実行する。 以上より、個人的には No.3 の  -v [Volume名]:[コンテナのディレクトリパス] を使っていきたい。 更に -v / --volume というオプションではあるが、上記3つの手順で共通していることは、ホスト側のディレクトリをコンテナ側への”マウント”処理である。 No.2 と No.3 の場合は「Volumeを作成してマウントする」,No.1の場合は「ホスト側のディレクトリをマウントする」ということ。 こういう背景があるからか最近では、 -v では無く --mount オプションで指定する方法が推奨されている模様。 --mount だと source=[volume名], target=[コンテナのディレクトリパス] のように属性値を明記したりできる。 Volume は、個別に作成しておくこともできる docker volume create [volue名] で先に作成しておいて、docker run 時にマウントすることができる。 その他、docker volume では Volumeの 一覧や詳細 が確認できる。 Docerfile のVOLUME dockerfile で定義できるVOLUME は、前述のNo.2 の コンテナのマウント先ディレクトリパスを指定するだけのもので、Volume名は定義することができなさそう。 つまり Volume名は定義できず、ハッシュ値となるので正直使い勝手は悪いと思う。 このため、docker run コマンド時に -vコマンドをつけ忘れて実行することを防止する以外の理由では 使わない方針にしたい。個人的には必ず -v や --mount オプションを付けることを忘れないようにしたい。 リンク コンテナにアクセスするときは exec と attach どちらの方がよい？ execの方が良いとのこと。（attachだと入った後に exit するとコンテナも終了するから。） attach は、コンテナの起動コマンド(エンドポイント) から入るイメージなので、exitしてもコンテナまで終了しない コンテナにファイルをコピーするコマンド 起動中のコンテナに、ホストOSのファイルをコピーする方法 （SCP コマンドみたいなもの） docker cp CONTAINER:SRC_PATH DEST_PATH docker cp SRC_PATH CONTAINER:DEST_PATH 前者が コンテナのファイルを ホストにコピーする場合。後者が、ホストのファイルをコンテナにコピーする場合。 コンテナ側は <コンテナID:コンテナ内のPath> とどのコンテナかも指定する事 このコマンドは出来る限り使うべきではないと思う。 コンテナの用途次第ではあるけども。 理由は コンテナは出来る限り ”ステートレス” で使うべきだから。 なので外部から コンテナ内の状態を変えるようなファイルのコピーは行うべきではない。 やるなら Dockerfileで恒久的に定義するべき。 なのでこのコマンドは 検証など一時的に利用するコンテナに対して使う。 本番環境など冗長的に使うコンテナでは利用しないようにする。 コンテナからのコピーもで本番環境であれば、元から必要なファイルをVolumeや外部ストレージファイルへ出力するように設計する。(ログファイルとか動的に生成・更新されるファイル) Dockerfile の WORKDIR の使い方 作業ディレクトリを指定するのが目的 指定したディレクトリが無ければ、作成しつつ移動することができる。 ADD と COPY と RUN の雑なまとめ どちらも ホスト側のファイルをコンテナ側に持って行くために利用する ADD の場合は、更にそのファイルが圧縮ファイルだと 展開まで行う。 ただしそのために、ADDを使った場合の方が、イメージファイルが多く作られ、結果としてサイズの大きいイメージが出来上がる。 なので展開する必要が無ければCOPYを使った方がよい。 とはいえどちらも実行するごとにイメージファイルが作られるし、外部ファイルをコンテナに持ってくること自体に色々と懸念がある。 （dockerfileを配布するときにホスト側で、リソースファイルを用意しないといけない。外部ファイルを使うことでセキュリティリスクが高まるなど） よって、できるだけADDもCOPYも使わずに、RUNを使って、コンテナ内でCurlやWgetなどでファイルをダウンロードして解凍するなどを行う方がよい。 更に言えば、RUNも実行するごとにイメージファイルが増えていくので、1つのRUN内で & を使って複数のコマンドを実行させたり、キャッシュを利用させることが最も望ましい。 マルチステージビルドで、アプリのビルド環境と実行環境を分ける マルチステージビルドは例えば、ビルド実行様に作ったイメージから、アプリの実行部分だけを取り出したイメージを作ることが出来る機能 Javaアプリなどで例えば、Mavenやgit、ひょっとしたらCurlなんかですら実際のアプリ環境で不要だとビルド環境をそのまま実行環境として使うと、余計なイメージサイズが増えるのでこれを削減する方法。 仮にMavenでもGradleでもラッパーで実行すればビルドツールのインストールは不要だけど、テスト用など実行環境では不要な依存関係は残ってしまうよね。 マルチステージビルドを使わなくても色々やりようはあるけど、要するに利用するイメージには不要なリソースは載せずに、サイズを軽くさせることを意識することが大事ということ。

社内Wikiに書いていたけど、個人開発でも参考にしたかったので転記しておく。 コンテナ立ち上げたけど Mavenインストールするの忘れた。後からインストールできる？ docker exec -it  --user root [CONTAINER] apt install maven ってコマンド実行すればできるよ。 普通に/bin/bash しても sudo が無いので apt でインストールができない --user root で root実行ができる。 コマンドは /bin/bash  にしなくても 直接 apt を実行すればいいよね。 Volumeについての雑なまとめ Volume は、コンテナ内のディレクトリを永続化するためのもの Volumeを作成するとまずホストPCにVolume用のディレクトリが作られ、コンテナにマウントする 作成されたVolumeは、コンテナを破棄しても削除されない Volumeの指定方法（作成方法） docker run の -v オプション 代表的なのは3パターン 使っていきたいのは、 No.3の Volume名を指定する方法。 -v [ホストのディレクトリパス]:[コンテナのディレクトリパス] -v [コンテナのディレクトリパス] -v [Volume名]:[コンテナのディレクトリパス] No.1 は厳密には、Bind mount と呼ばれる設定を行っている。Bind mountは、ホスト側の既存ディレクトリをそのままコンテナ側にマウントする使い方である。なのでVolumeという概念とはちょっと異なる。（更に最近だと非推奨という話も挙がっていた） このため、Volumeを作成しているのは No.2 と No.3 のみ。この2つの違いは主にVolumeの命名。前者はハッシュ値を名称に割り当てるのに対して、後者は任意の名称を指定できるのでどのコンテナで利用しているVolumeかが分かりやすい。 指定したVolumeが ホスト側のどこに存在するかを知りたい場合は、 docker volume inspection [Volume名] を実行する。 以上より、個人的には No.3 の  -v [Volume名]:[コンテナのディレクトリパス] を使っていきたい。 更に -v / --volume というオプションではあるが、上記3つの手順で共通していることは、ホスト側のディレクトリをコンテナ側への”マウント”処理である。 No.2 と No.3 の場合は「Volumeを作成してマウントする」,No.1の場合は「ホスト側のディレクトリをマウントする」ということ。 こういう背景があるからか最近では、 -v では無く --mount オプションで指定する方法が推奨されている模様。 --mount だと source=[volume名], target=[コンテナのディレクトリパス] のように属性値を明記したりできる。 Volume は、個別に作成しておくこともできる docker volume create [volue名] で先に作成しておいて、docker run 時にマウントすることができる。 その他、docker volume では Volumeの 一覧や詳細 が確認できる。 Docerfile のVOLUME dockerfile で定義できるVOLUME は、前述のNo.2 の コンテナのマウント先ディレクトリパスを指定するだけのもので、Volume名は定義することができなさそう。 つまり Volume名は定義できず、ハッシュ値となるので正直使い勝手は悪いと思う。 このため、docker run コマンド時に -vコマンドをつけ忘れて実行することを防止する以外の理由では 使わない方針にしたい。個人的には必ず -v や --mount オプションを付けることを忘れないようにしたい。 リンク コンテナにアクセスするときは exec と attach どちらの方がよい？ execの方が良いとのこと。（attachだと入った後に exit するとコンテナも終了するから。） attach は、コンテナの起動コマンド(エンドポイント) から入るイメージなので、exitしてもコンテナまで終了しない コンテナにファイルをコピーするコマンド 起動中のコンテナに、ホストOSのファイルをコピーする方法 （SCP コマンドみたいなもの） docker cp CONTAINER:SRC_PATH DEST_PATH docker cp SRC_PATH CONTAINER:DEST_PATH 前者が コンテナのファイルを ホストにコピーする場合。後者が、ホストのファイルをコンテナにコピーする場合。 コンテナ側は <コンテナID:コンテナ内のPath> とどのコンテナかも指定する事 このコマンドは出来る限り使うべきではないと思う。 コンテナの用途次第ではあるけども。 理由は コンテナは出来る限り ”ステートレス” で使うべきだから。 なので外部から コンテナ内の状態を変えるようなファイルのコピーは行うべきではない。 やるなら Dockerfileで恒久的に定義するべき。 なのでこのコマンドは 検証など一時的に利用するコンテナに対して使う。 本番環境など冗長的に使うコンテナでは利用しないようにする。 コンテナからのコピーもで本番環境であれば、元から必要なファイルをVolumeや外部ストレージファイルへ出力するように設計する。(ログファイルとか動的に生成・更新されるファイル) Dockerfile の WORKDIR の使い方 作業ディレクトリを指定するのが目的 指定したディレクトリが無ければ、作成しつつ移動することができる。 ADD と COPY と RUN の雑なまとめ どちらも ホスト側のファイルをコンテナ側に持って行くために利用する ADD の場合は、更にそのファイルが圧縮ファイルだと 展開まで行う。 ただしそのために、ADDを使った場合の方が、イメージファイルが多く作られ、結果としてサイズの大きいイメージが出来上がる。 なので展開する必要が無ければCOPYを使った方がよい。 とはいえどちらも実行するごとにイメージファイルが作られるし、外部ファイルをコンテナに持ってくること自体に色々と懸念がある。 （dockerfileを配布するときにホスト側で、リソースファイルを用意しないといけない。外部ファイルを使うことでセキュリティリスクが高まるなど） よって、できるだけADDもCOPYも使わずに、RUNを使って、コンテナ内でCurlやWgetなどでファイルをダウンロードして解凍するなどを行う方がよい。 更に言えば、RUNも実行するごとにイメージファイルが増えていくので、1つのRUN内で & を使って複数のコマンドを実行させたり、キャッシュを利用させることが最も望ましい。 マルチステージビルドで、アプリのビルド環境と実行環境を分ける マルチステージビルドは例えば、ビルド実行様に作ったイメージから、アプリの実行部分だけを取り出したイメージを作ることが出来る機能 Javaアプリなどで例えば、Mavenやgit、ひょっとしたらCurlなんかですら実際のアプリ環境で不要だとビルド環境をそのまま実行環境として使うと、余計なイメージサイズが増えるのでこれを削減する方法。 仮にMavenでもGradleでもラッパーで実行すればビルドツールのインストールは不要だけど、テスト用など実行環境では不要な依存関係は残ってしまうよね。 マルチステージビルドを使わなくても色々やりようはあるけど、要するに利用するイメージには不要なリソースは載せずに、サイズを軽くさせることを意識することが大事ということ。

概要 docker環境でchromeでのブラウザテストを実行した際に今まで通っていたテストが "invalid session id"のエラー発生したので解消方法を記載します。 エラー内容 Selenium::WebDriver::Error::InvalidSessionIdError: invalid session id 原因と解決方法 【原因】 どうやらメモリ不足が原因みたいでした。 【解決方法】 chromeコンテナのメモリを増やすように設定を行う。 → docker-compose.ymlを修正してコンテナで使用するメモリを設定します。 docker-compose.yml chrome: image: selenium/standalone-chrome:latest shm_size: 256m　　#　←　追加 ports: - 4444:4444 shmサイズは、Chromeがコンテンツをダウンロードした際の一時ファイル領域のことです。 デフォルトは64mらしいので、多めに設定してみます。 設定後テストが通るようになりました。

はじめに 備忘録記事なのでわかりづらいかもです。 オンプレ環境を想定して、まずはcentos7のコンテナを起動し、そこに必要なものをインストールしていく手順を取ってます。 ※docker-composeは使わない。 Fluentd検証環境構築 dockerコンテナ起動 ※sudo使うために「--privileged」で「/sbin/init」を起動時に実行している。(システム起動時に実行することでprocessNo=1に/sbin/initが実行されるようになる) $ docker run --privileged -d -v `pwd`:`pwd` -it --rm --name centos_like_work_env centos:centos7 /sbin/init $ docker exec -it centos_like_work_env /bin/bash Fluentdのインストール $ cat /etc/redhat-release CentOS Linux release 8.3.2011 $ yum update -y && yum upgrade -y $ yum install -y wget curl sudo $ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh | sh // 省略 Error: Package: td-agent-4.1.1-1.amzn2.x86_64 (treasuredata) Requires: libc.so.6(GLIBC_2.25)(64bit) Error: Package: td-agent-4.1.1-1.amzn2.x86_64 (treasuredata) Requires: libncurses.so.6()(64bit) Error: Package: td-agent-4.1.1-1.amzn2.x86_64 (treasuredata) Requires: libtinfo.so.6()(64bit) エラーが出た。 $ yum whatprovides libc.so.6 Loaded plugins: fastestmirror, ovl Loading mirror speeds from cached hostfile * base: ty1.mirror.newmediaexpress.com * extras: ty1.mirror.newmediaexpress.com * updates: ty1.mirror.newmediaexpress.com glibc-2.17-317.el7.i686 : The GNU libc libraries Repo : base Matched from: Provides : libc.so.6 glibc-2.17-322.el7_9.i686 : The GNU libc libraries Repo : updates Matched from: Provides : libc.so.6 glibc-2.17-323.el7_9.i686 : The GNU libc libraries Repo : updates Matched from: Provides : libc.so.6 glibc-2.17-324.el7_9.i686 : The GNU libc libraries Repo : updates Matched from: Provides : libc.so.6 $ yum whatprovides libncurses.so.6 No matches found $ yum whatprovides libtinfo.so.6 No matches found 以上より、「glibc」を入れて（更新して）みた。 ※「glibc」は、「ジーリブシー」と読み、「GNU C Library」の意味。「GNU Project」によるC言語の標準ライブラリ「libc（リブシー）」 $ yum clean all $ yum -y update glibc で、再度Fluentdのインストールを試みる！ $ curl -L https://toolbelt.treasuredata.com/sh/install-redhat-td-agent4.sh | sh 成功！ Fluentdデーモン起動 $ systemctl status td-agent ● td-agent.service - td-agent: Fluentd based data collector for Treasure Data Loaded: loaded (/usr/lib/systemd/system/td-agent.service; enabled; vendor preset: disabled) Active: inactive (dead) Docs: https://docs.treasuredata.com/display/public/PD/About+Treasure+Data%27s+Server-Side+Agent $ sudo systemctl start td-agent Job for td-agent.service failed because a timeout was exceeded. See "systemctl status td-agent.service" and "journalctl -xe" for details. 起動失敗した。 $ systemctl status td-agent.service ● td-agent.service - td-agent: Fluentd based data collector for Treasure Data Loaded: loaded (/usr/lib/systemd/system/td-agent.service; enabled; vendor preset: disabled) Active: activating (start) since Tue 2021-06-01 02:35:42 UTC; 20s ago Docs: https://docs.treasuredata.com/display/public/PD/About+Treasure+Data%27s+Server-Side+Agent Process: 557 ExecStart=/opt/td-agent/bin/fluentd --log $TD_AGENT_LOG_FILE --daemon /var/run/td-agent/td-agent.pid $TD_AGENT_OPTIONS (code=exited, status=0/SUCCESS) CGroup: /docker/732f8c59988d831be02224cce0fc0618f6a0d85c43166bc8b4d03033d7eb3654/docker/732f8c59988d831be02224cce0fc0618f6a0d85c43166bc8b4d03033d7eb3654/system.slice/td-agent.service ├─563 /opt/td-agent/bin/ruby /opt/td-agent/bin/fluentd --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td-agent.pid └─566 /opt/td-agent/bin/ruby -Eascii-8bit:ascii-8bit /opt/td-agent/bin/fluentd --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td-agent.pid --under-supervisor Jun 01 02:35:42 732f8c59988d systemd[1]: Stopped td-agent: Fluentd based data collector for Treasure Data. Jun 01 02:35:42 732f8c59988d systemd[1]: Starting td-agent: Fluentd based data collector for Treasure Data... Jun 01 02:35:43 732f8c59988d systemd[1]: New main PID 563 does not belong to service, and PID file is not owned by root. Refusing. Jun 01 02:35:43 732f8c59988d systemd[1]: New main PID 563 does not belong to service, and PID file is not owned by root. Refusing. いろいろ調べて以下のように起動するユーザーをrootに修正してみた。 $ vi /usr/lib/systemd/system/td-agent.service [Service] User=root # User=td-agent Group=root # Group=td-agent 再度Fluentdの起動を試みる！ $ sudo systemctl restart td-agent.service $ systemctl status td-agent.service 成功！ Fluentdの自動起動設定だけ追加でしておく $ systemctl enable td-agent.service Fluentdのプロセスを確認 $ yum clean all $ yum -y update ps $ ps auxf | grep td-agent root 988 0.0 0.0 9104 924 pts/1 S+ 12:58 0:00 \_ grep --color=auto td-agent root 920 0.1 1.9 266196 40428 ? Sl 07:54 0:22 /opt/td-agent/bin/ruby /opt/td-agent/bin/fluentd --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td-agent.pid root 923 0.2 2.4 280444 49300 ? Sl 07:54 0:44 \_ /opt/td-agent/bin/ruby -Eascii-8bit:ascii-8bit /opt/td-agent/bin/fluentd --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td-agent.pid --under-supervisor 親子関係がわかる。 簡易監視スクリプトの配置 Fluentdより実行する簡易的なシェルスクリプトを先に配置しておく。 シェルスクリプトは以下の通り。 CPU監視を想定した簡易スクリプト #!/bin/bash #CPU使用率閾値 100%=100で記載。閾値を超えるようにあえて2に設定。 CPU_LIMIT=2 #CPU使用率取得 CPU_USED=`vmstat | sed '1, 2d' | awk '{print $13 + $14}' | awk '{printf("%d\n",$1)}'` #CPU使用率の閾値チェック if [ $CPU_USED -ge $CPU_LIMIT ]; then echo "cpu over $CPU_USED%, hostname is $HOSTNAME" fi メモリ監視を想定した簡易スクリプト #!/bin/bash #メモリ閾値 100%=100で記載。閾値を超えるようにあえて80に設定。 MEM_LIMIT=80 #メモリ使用率取得 MEM_USED=`free | grep Mem | awk '{ print ($2-$3)/$2*100 }' | awk '{printf("%d\n",$1)}'` #メモリ使用量の閾値チェック if [ $MEM_USED -ge $MEM_LIMIT ]; then echo "memory over $MEM_USED%, hostname is $HOSTNAME" fi スワップ監視を想定した簡易スクリプト #!/bin/bash #スワップ閾値 100%=100で記載。閾値を超えるよにあえて10に設定。 SWAP_LIMIT=10 #スワップ使用率取得 SWAP_USED=`free | grep Swap | awk '{ print $3/$2*100 }' | awk '{printf("%d\n",$1)}'` #スワップ使用量の閾値チェック if [ $SWAP_USED -ge $SWAP_LIMIT ]; then echo "swap over $SWAP_USED%, hostname is $HOSTNAME" fi 以下のコマンドで、Slackプラグインのインストールをした。 Slackプラグインのインストールと、 以下を参考にwebhook urlの取得をした。 https://cly7796.net/blog/other/send-a-message-to-slack-using-the-incoming-webhook/ Fluentdの設定ファイルを編集 既存のtd-agent.confをバックアップ $ mv /etc/td-agent/td-agent.conf /etc/td-agent/default-td-agent.conf 設定ファイルを作成 $ vi /etc/td-agent/td-agent.conf 以下のように記述した。 <source> @type exec tag check.cpu run_interval 30s command sh /Users/fukazawakeisuke/training/centos_like_work/check_cpu.sh format none </source> <source> @type exec tag check.memory run_interval 30s command sh /Users/fukazawakeisuke/training/centos_like_work/check_memory.sh format none </source> <source> @type exec tag check.swap run_interval 30s command sh /Users/fukazawakeisuke/training/centos_like_work/check_swap.sh format none </source> <match check.*> @type slack webhook_url https://hooks.slack.com/services/T021RTXSF2M/B02444USS9Y/ j7AcHMKnoKUuIatQOZhe17Kw channel er-playground color warning message %s message_keys message flush_interval 10s </match> td-agentを再起動する $ systemctl restart td-agent.service fluentdのログファイルを確認。 Slackに通知が行かないなど、Fluentdがうまく動いていない場合はここにログが出ているはず。 なおFluetndのoutputプラグインでの標準出力もここに出力される。 $ tail -f /var/log/td-agent/td-agent.log 動かすまでに作成したfluentdの設定ファイル達 バージョン1 <source> @id in_forward @type forward port 24224 </source> <match test.**> @type stdout </match> 動作検証コマンド $ echo '{"user":"1","message":"Hello World"}' | /opt/td-agent/bin/fluent-cat test.debug バージョン2 <source> @type exec tag in_exec_test command sh /Users/fukazawakeisuke/training/centos_like_work/ surveillance_memory.sh format none run_interval 30s </source> <match in_exec_test> @type file path /tmp/in_exec_test.log </match>

現場でDockerを使う現場で作業したことはあるが仕組みが曖昧で、完全に理解したわけではないので参考書を読みつつ、初心に戻り、まとめてみることにしました。 本来のシステムや機能の仕組み 本来、システムや機能は、以下のようにサーバー内にいろんなフレームワークだったり、様々なプログラムやソフトウェアが存在していて、動いています。 そして、それらはそれらを動かすための実行環境だったり、他のプログラムを元に動いていたりすることがあるのです。 また、システムやソフトウェアは共通の実行環境だったり、ライブラリを使用していることだって少なくありません。 そして各々のシステムが作動するversionが決まっていることもあり、共通のプログラムがそれに対応していないと、一部のシステムが動かなくなってしまいます。 Dockerは一つのサーバーに複数の実行環境を構築するもの こういった問題を解決するものとして、Dockerというものがあります。 Dockerとは、サーバー内の様々なシステムやプログラムの実行環境をシステム・プログラムごとに作成できるシステムです。 つまり、一つのサーバーに ○Laravelなら、PHPの実行環境 ○Nuxtなら、Nodeの実行環境 を構築することができ、システムにあった環境を用意することができます。 そして、その実行環境のことを「コンテナ」と言います。 そして、そのコンテナの種類のことを「イメージ」といい、コンテンはイメージをもとに作成されます。 DockerはLinuxで動く DockerはLinuxで動くので、Dockerの操作をするとき(Dockerを起動する、Docker内のコンテナを移す、削除するetc...)はLinuxのコマンドで操作したりします。 そもそもサーバとは そもそもサーバって何なのかも合わせて調べてみました。 サーバとは英語で書くと、「Server」と書き、Serve(割り当てる、給仕する)という動詞から成り立っている言葉であり、これの名詞型になるとサービス(Service)となります。 つまり、サーバとは何かを提供するものということです。 ○「Webサーバ」と言えば、Web関係の機能が格納されたサーバ ○「メールサーバ」と言えば、メール関係の機能が格納されたサーバ というように。 そして、サーバは大きく分けて、 ○総合的なサーバ ○部分的なサーナ の2つに分けることができます。 Dockerの構造 まずは復習として、Dockerは大体以下のような構造になっています。 もともと使用しているサーバーOSがあり、そのサーバーOSはLinux　OSで作動し、さらにその上でDockerがあるのです。 そして、Dockerのコンテナの中には、コンテナごとのそのコンテナ専用のLinux OSが存在しています。 ちなみに、OSとは「Operating System(オペレーティング・システム)」の略で、ユーザの命令をシステムや機械に伝えるものです。 世の中の機械やシステムは単純であり、人間のように思考回路があるわけではないので、人間のしたいことを伝えてもそのままでは、機械は理解できません。 つまり、OSとは、人間の言葉を機械に変換するためのものなのです。 以上、まずはDockerがどんなものかをまとめてみました。

はじめに ここ一ヶ月半くらいかけて比較的新しいWeb制作技術を取り入れたサービスを個人的に作ってみましたので、使用した技術やサービスの紹介をしたいと思います。 作ったサービス フォーラムがメインのSNS 詳細は伏せるが、デザインはredditを意識して作成した。 ※イメージ図 開発を行った経緯 トレンドのフロントエンド技術のSPAとクラウドサービスの理解を深めるために開発に着手しました。 使用した技術やサービス できるだけ新しいものを選定 フロントエンド関連 　React.js SPA（シングルページアプリケーション）で作りたかったことと、VueやAngulerに比べて昨今の勢いが好調なところが採用のポイント。 本当はNext.jsで作る予定だったが、Firebaseとの親和性が低く、開発元であるVercelのホスティングサービスを利用することが前提に近かったため、今回は見送りした。 使用したライブラリや機能 Reactの機能やライブラリはトレンドの変化に変わるので、開発開始時点でのトレンドを把握してから着手した方が良いと思う。 hook React 16.8 （２０２０年）で追加された新機能です。state（状態管理用変数）やライフサイクル（constructor,didmount） などの Reactの機能を、クラスを書かずに使えるようになる現時点での必須機能です。 React Router アクセスされたURLによって、表示を切り替えることができるライブラリ。 これを使わないとソースコードがゴチャゴチャし、大規模開発になると管理が大変になります。 Redux ブラウザアプリケーションのための状態管理コンテナライブラリ。 R- eact単体の機能だとstate(静的変数とかcookieに近いイメージ)は自身のコンポーネントで使用するか、props（引数）を通して子コンポーネントへ送ることしかできないが、Reduxを使うとstateを高域変数の様に扱うことができる様になる。 管理方法もフレームワーク化されているため、煩雑な扱いでコードの可読性が低下することもない。 フレームワーク自体が複雑な欠点があり、理解にはかなり時間を費やしたかも・・・ ※以降の開発ではReactの提供する状態管理機能のRecoilを使った方が学習コストが低そうなので、そちらの方がおすすめ、現在はベータ版だが、そろそろ正式リリースされる予定。 使用言語 Typescript JavaScriptに型制約を追加したもの。 コードの可読性の向上や、意図しないバグを防いだりできる。 JavaScriptと構文はほぼ同じなので、学習コストは低い。 型の記述方法はC#とかJavaとかの言語とは少し異なるので、最初は違和感を感じるが慣れの問題。 interfaceの機能があるが、他の言語とは用途が少し異なり、拡張可能な型定義の機能を持っており、プロパティの定義に使われたりすることが多い。ちなみに拡張しない場合はTypedで定義する。 CSSフレームワーク Tailwind CSS 最近のトレンドらしいのでメインはこれを使用 簡単に扱うことができるが、日本語情報はまだまだ少ないので、BootStorapの方が初心者向け。 BootStrapと同じような感覚で使用できるが、比較すると色々な所が少し細かく設定できるイメージ。 個人的にはデザインスキルがまだまだ低いので、これに限らずCSS関連はいつも苦戦する。 Material UI Reactと親和性が高い（らしい）。 テキストボックスのプレースホルダがカッコよく動くのでそこだけ利用した。 バックエンド関連 Firebase 手軽に一定範囲まで無料で使えるので個人開発で人気のクラウドサービス スマホアプリやWeb用のクラウドサービス、元々別会社だったがGoogleに買収されたのでGCPと同じサービスがあったりする。 今回は使っていないがAndroidのPUSH通知はFirebaseしか使えなかったりするらしい（ホント？） oauth機能が簡単に扱えるため、oauth機能はかなり人気で、オンプレで制作してoauthだけFirebaseとか結構あるらしい。 各サービスに無料枠があり、個人で使う分には変な作り方をしない限り無料で収まる。開発中のテストでも無料枠の1％を超えることがなかった。 使用したFirebaseの機能 Authentication 簡単にログイン機能を実装できて、自分で個人情報の管理をしなくて良いので使用した。 googleとかtwitterとかの外部認証を簡単に実装できる。 GUIライブラリreact-firebaseuiを使うとさらに簡単に実装できる。 RealtimeDatabase Json形式のデータベース 帯域に対して課金される。同じデータベースサービスのFireStoreでは、アクセス回数で課金されるので、頻繁にReadする用途に向いている。 Googleの推奨はオブジェクト形式のFirestoreで当初はFireStoreを使用していたが、課金方式的に用途に適していなかったので途中でこちらに変更した。 単純なクエリが設定できないので、粗い条件で一旦取得して、ローカルのTSでソートやフィルタをかけて使う。この辺はFireStoreも変わらない。 Storage ファイルストレージサービス FIrebaseのファイル管理はこれ一択、画像の保存に使用した。 Hosting Reactのプロジェクトを格納するのに使用 静的なファイルはここに格納する。 デフォルトで設定するとPublicフォルダにアクセスしようとするので、Buildフォルダにアクセスするように設定することが重要 Function サーバーレスコンピューティングサービス SlackやTwitterのAPIと組み合わせてメッセージを飛ばせるようにした。 ドメイン取得サービス ムームードメイン 前から使っていたので、今回もここから取得 以前初期費用が安い".xyz"を使ったことがあったが、年間維持費を意識していなかったので失敗したので、使いたいドメインが空いていたこともあり、今回は１０００円程度で維持できる.comで取得した。 外部サービス slack API 問い合わせ画面で問い合わせをするとSlackでメッセージが飛ぶように設定 twitter API Webサービスの各種情報発信用にTwitterの連携したアカウントでツイートするように設定 開発環境 windows環境 wsl2 + vscode(remote wsl) Windows上でほぼ完全なLinux（Ubuntu）を動作させることができ、Windowsのファイルシステムにそのままアクセスできたりする。※GUI版も２０２１年にリリースされたが、こちらは使用していない。 react開発環境のnodeがバージョン制約にかなり厳しいので、仮想環境として利用した。 ２つ以上環境を作りたい場合、環境が作れるか謎。どうすれば良いか調べてないが、多分そういう用途だとDockerでやった方が良さそう。 ※途中で何回かnode関連のアップデートをしてしまい、環境再構築に手間取ったので、すぐに復元できるDockerは偉大。 Mac（M1）環境 Docker + vscode(remote container) みんな大好きDocker remote containerを使うとローカル作業とほぼ同じ感覚で開発することができる。 最初にdockerファイルを作るのが面倒 dockerHubにイメージを保管できるので、環境が消えても安心（Dockerファイルはgitで管理？） バージョン管理 GitHub 選定理由は人気で情報が多いから。 次回以降は競合のGitLabで作ろうと思う。 2020年にCI/CD機能GitHub Actionsが追加されたので、こちらも実装し、git pushを実行するとreactプロジェクトのビルドとFirebaseへのデプロイが自動で実行される様にしてみた。 必須VSCode拡張機能 Prettier 大人気の自動整形拡張機能 ソースコードを保存すると自動で整形されるので、整形忘れを防止できる。 （個人で使ったが）グループでの開発に向いており、バージョン管理のソースコードが荒れにくく減る。 タスク管理 Trello プロジェクトのタスクをチームで管理するためのサービス。 トヨタの生産管理方式“カンバン”の運用ができる。 タスク（チケット）発行が楽で５秒で発行できる。 スマホ版もしっかり作られている。 使いたかったサービス Webデザインツール Figma トレンドのWebデザインツールらしい デザイン通りにCSSを組める自信が無いのと、デザインは重視してなかったので使わなかった。 デザインできる人は尊敬します。 感想など SPAはほぼ知識ゼロに近い状態からスタートしたので、慣れるまでかなり時間が掛かったのと、学習コストが結構高かった。 reactは2年前に少し触ったが使用するライブラリや機能のトレンドが代わり過ぎてて知識が使い物にならないので、フロントエンドの流れの速さに驚いた。自分の持ってた2年前の書籍が使いものにならない、書籍買う人は注意。 全体的に触ったことがないものばかりだったため、インプット量が多く、辛い道のりだったが、今回で一気にWEB系の技術や知識などの引き出しが増えたので少し自信がついた。 今回の進め方について 今回は開始前にラーニングピラミットやアクティブラーニングなどの学習方法について学んでから開発を進めていた。Qiitaに最近ちょくちょく投稿し始めたのもそれの関係。 アクティブラーニングを意識し、ほぼ書籍を読まずに手探りで進め、分からなかったところを中心に調べる方式で進めたが、体験と結びつけて学習ができたためか、かなり効率的に吸収できた気がする。 着手前に本を読んだ場合、記憶力が悪いので後半に差し掛かると本の前半の内容を忘れてしまうので、こちらの方が効率的に感じた。 これまでは、勉強してから手を動かしていたので非効率だったことに後悔するも、これからに期待 以上

こんにちは、まゆみです。 Dockerについての記事をシリーズで書いています。 今回は ビルドコンテキスト内のファイルをアップデートしたい時、アップデートする必要のないファイルがある時はどうしたら良いのか？ ということについて書いていきます。 抽象的で少しわかりにくいので、具体的に言いますね。 第8回目の記事で、ビルドコンテキスト内に『Dockerfile』『index.js』『package.json』を用意してbuild する方法をお伝えしました。 上記のような状況である時、仮に、index.jsファイルの中身のみを書き換えて、package.jsonは一番最初にbuild した時のキャッシュを利用したいという時のDockerfile の書き方を書いていきます DockerfileからImageを作るには下記のように書く場合が多いと思います。 FROM　ベースのイメージ WORKDIR ワーキングディレクトリを指定する COPY Containerにコピーしたいファイルを指定 RUN このような書き方だと、その後もファイルを書き換えることはないという時は良いと思います。 ただ ①index.jsの中身を書き換えて ②再び『docker build .』する時 ③Dockerfileの『COPY ./ ./』で不要なpackage.jsonまでCOPYされ、キャッシュが活用できないという事態になり、 再buildに余分な時間がかかってしまいます。 では、今回の記事の概要を伝えたところでさっそく具体的に解説していきます 今回使うファイル ポートマッピングをして、localhost:8080にアクセスすると、『こんにちは』と表示してくれるアプリを作りました。 うまく行っています。 ではindex.jsの中の『こんにちは』というテキストを『さようなら』に変えてみます index.jsを保存し、localhost:8080をリロードしましたが、ファイルの変更は反映されず、表示は『こんにちは』のままです これは、Imageを再び作りなおす必要があります このままDockerfile を書き換えないで、一からbuild してみました。 localhost:8080をリロードすると、『さようなら』に書き換えられましたが、『COPY ./ ./』の時点で、COPYする必要のないpackage.jsonまでCOPYされ、step 3 以降のプロセスもキャッシュが活用されず、全て一から作りなおされているのが分かると思います index.jsのたった1行を書き換えただけなのに、最初にbuildした時のキャッシュを活用できないのは、嫌ですよね。 解決方法 では、やっと本題に入ります。 rebuildした時に、書き換えた部分のみ上書きして他の部分は最初にbuildした時のキャッシュを活用するようにDockerfileを書き換えてみます FROM node:alpine WORKDIR /usr/app COPY ./package.json ./ RUN npm install COPY ./ ./ CMD ["npm", "start"] 上記のコードを解説します まず 3行目に COPY ./package.json ./ とありますが、4行目でnpmをインストールするとき、package.jsonは必要なファイルなので『そのファイルのみ』は最初にCOPYしておきます そして RUN　npm install でnpmをインストールした後、package.json以外にも必要なファイルも『含めてすべて』COPYします。 ただその後、ファイルを書き換えてImageをrebuildする必要が出てきた場合も、 FROM node:alpine WORKDIR /usr/app COPY ./package.json ./ RUN npm install 上記のプロセスは、前回にbuildをした時のキャッシュが活用できるようになるのです。 COPY ./ ./ CMD ["npm", "start"] 上記の2行分のみのプロセスが作り替えられることになります この解決法のDockerfileを使って、Imageをbuildして、index.jsの一行を書き換え、再びbuildしてみましょう 実行結果は上記のようになります。 step 5 の『COPY ./ ./』までは全て Using cache と書かれていて、キャッシュが活用されているのが分かります 今回わかったこと Docker Image が作られる時、stepごとにベースイメージに変更が加えられながら作られていきます その後ファイルに変更が加えられ、rebuildする時、例えばstep 4で変更があれば、それ以降のプロセスは全て新しく作り直されることになります Dockerfileの書き方によっては、rebuildの際、本来ならキャッシュを活用すべきところも、新しく作りなおされる場合もあるので、最初にDockerfile を書く時点で、あとのことも考慮に入れながら書くと良いと思います。 今回の記事は、ここで締めくくらせていただきますね。 お役に立てれば嬉しいです。

エラー 以下の Dockerfile をもとにビルドする FROM public.ecr.aws/lambda/python:3.8 COPY . ${LAMBDA_TASK_ROOT} RUN pip install -r requirements.txt CMD ["app.handler"] すると以下のようにエラーが出た アクセス権がない様子 $ docker build -t iconow-lambda . [+] Building 1.1s (3/3) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 31B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => ERROR [internal] load metadata for public.ecr.aws/lambda/python:3.8 0.9s ------ > [internal] load metadata for public.ecr.aws/lambda/python:3.8: ------ failed to solve with frontend dockerfile.v0: failed to create LLB definition: unexpected status code [manifests 3.8]: 403 Forbidden 解決策 以下を叩いて認証を得る aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws

はじめに 私が普段よく使うコマンドをまとめています。 DockerイメージからGPUを割り当てたコンテナ生成は別のスクリプトファイルを用意しているのでそこは覚えていないです。 dockerのイメージの一覧を見る $ docker image dockerコンテナの一覧を表示する オプションをつけないと起動中のコンテナのみ表示する。"-a"をつけること停止中のもの含めてすべてを表示する。 $ docker ps $ docker ps -a dockerのリソースの使用率を監視する $ docker stats 作成済みのコンテナを起動する。 $ docker start vm dockerを停止する。削除する。 $ docker stop vm コンテナ「vm-name」に入るためのコマンドの実行する。 コンテナから抜けてもコンテナは停止しない。 $ docker exec -it vm-name bash GPUの情報を表示する。2秒おきに監視する。 $ watch -n 2 nvidia-smi $ nvidia-smi --l 2 ストレージの使用率の確認方法。 $ sudo du -h -d 1 $ df 用法がわからないとき わからないときは調べる。 $ du --help 実行中のプロセスを見る $ ps aux | grep httpd ログの場所を調べる $ ls -l /proc/{プロセスのID}/fd 再帰的にパーミッション変更 $ find /path/to/dir -type d -exec chmod 777 {} + $ find /path/to/dir -type f -exec chmod 777 {} +