環境 製品 : Synology DS720+ DSMバージョン : DSM 7.0.1-42218 メモリを10GBに拡張済み Docker パッケージセンターより20.10.3-1239をインストール済み コンテナ作成 レジストリよりubuntu:latestをダウンロードする。 詳細設定より、任意のDSM上のフォルダを/dataにマウントする。(後で利用するため) その他は特に変更せずダウンロードしたイメージからコンテナを作成する。 端末に接続 起動したコンテナの詳細画面より端末に接続する。 これ以降の手順でDSM画面上の端末にコマンドを貼り付ける際、一度Ctrl+Aを入力してプレフィックスモードに入ってからCtrl+Vで貼り付けることができる。 docker上の操作ではsudoを付ける必要はない(?) XMRigをビルド 参考 必要なパッケージをインストール 利用しているイメージは最低限のコマンドしか利用できないため、必要なパッケージをインストールする。 apt-get update apt-get install git build-essential cmake libuv1-dev libssl-dev libhwloc-dev -y tzdataの設定時にタイムゾーンを訊ねられた場合は、Asia、Tokyoとなるように選択する。 ソースコードを取得 cd ~ git clone https://github.com/xmrig/xmrig.git ソースコードを編集 デフォルトでは寄付の割合が1%と設定されているため、0%に変更する。 sed -i -e "s/DonateLevel = 1;/DonateLevel = 0;/g" ~/xmrig/src/donate.h ビルド mkdir xmrig/build && cd xmrig/build cmake .. make -j$(nproc) configurationsファイルを用意する こちらのドキュメントやデフォルト設定ファイル、ウィザードを参考にconfig.jsonファイルを用意し、コンテナにマウントしているフォルダに配置する。 以下はnicehashを利用する設定ファイルの例。 { "autosave": true, "cpu": true, "opencl": false, "cuda": false, "pools": [ { "coin": null, "algo": "rx/0", "url": "randomxmonero.usa-west.nicehash.com:3380", "user": "<マイニングウォレットアドレス>.synology", "pass": "x", "tls": false, "keepalive": true, "nicehash": true } ] } XMRigを実行 ~/xmrig/build/xmrig -c /data/config.json 以下のような初期表示が出力された後にマイニングが開始される。 * ABOUT XMRig/6.16.0 gcc/9.3.0 * LIBS libuv/1.34.2 OpenSSL/1.1.1f hwloc/2.1.0 * HUGE PAGES supported * 1GB PAGES disabled * CPU Intel(R) Celeron(R) J4125 CPU @ 2.00GHz (1) 64-bit AES L2:4.0 MB L3:0.0 MB 4C/4T NUMA:1 * MEMORY 7.1/9.6 GB (74%) * DONATE 1% * ASSEMBLY auto:intel * POOL #1 randomxmonero.usa-west.nicehash.com:3380 algo rx/0 * COMMANDS hashrate, pause, resume, results, connection [2021-11-28 02:08:24.771] config configuration saved to: "/data/config.json" * OPENCL disabled * CUDA disabled randomxmoneroをrx/0アルゴリズムでマイニングした際に315 H/sほど出る模様。

everyday-railsというテスト本を元にdocker環境で学習しようとしたのがことの発端です。 私自身dockerのことをよくわかっていなかったので、なかなか解決に時間がかかってしまいました。 前提 この記事では、docker-composeにrailsの環境(everyday-railsで用意されているソースを元に使います。)を構築するにあたって遭遇したエラーとその対処について書きます。 Dockerファイルなど dockerファイル dockerfile FROM ruby:2.7 ENV LANG C.UTF-8 RUN apt-get update -qq && apt-get install -y \ build-essential \ nodejs \ && rm -rf /var/lib/apt/lists/* RUN gem install bundler WORKDIR /tmp ADD Gemfile Gemfile ADD Gemfile.lock Gemfile.lock RUN bundle install ENV APP_HOME /myapp RUN mkdir -p $APP_HOME WORKDIR $APP_HOME ADD . $APP_HOME docker-compose.yml docker-compose.yml version: '3' services: web: build: . ports: - "3000:3000" command: bundle exec rails s -p 3000 -b '0.0.0.0' volumes: - .:/myapp - bundle:/usr/local/bundle depends_on: - db db: image: mysql:5.7 environment: MYSQL_ROOT_PASSWORD: password ports: - '3306:3306' volumes: - mysql_data:/var/lib/mysql volumes: bundle: mysql_data: database.yml(config/database.ymlのことです。) database.yml default: &default adapter: mysql2 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> timeout: 5000 username: root password: password host: db development: <<: *default database: development_database test: <<: *default database: test_database production: <<: *default database: production_database Gemfile Gemfile # gem 'sqlite3' ↑これを消して gem 'mysql2'とします これは今回使うデータベースがmysqlのためです。 docker-composeを立ち上げる ここまででdocker-composeの設定となるファイルを書いたら、docker-composeを立ち上げます。 コマンドは ターミナル docker-compose build 何も問題なければ、以下のようにターミナルに表示されるはずです。 ➜ everydayrails-rspec-2017 git:(master) ✗ docker-compose ps NAME COMMAND SERVICE STATUS PORTS ➜ everydayrails-rspec-2017 git:(master) ✗ docker-compose build [+] Building 1.5s (15/15) FINISHED => [internal] load build definition from Dockerfile 0.0s => => transferring dockerfile: 32B 0.0s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/ruby:2.7 1.3s => [ 1/10] FROM docker.io/library/ruby:2.7@sha256:2b5ffc71a256f93e98a1b596f38bbe33632c5c48138f939aae7347e65343383f 0.0s => [internal] load build context 0.0s => => transferring context: 13.34kB 0.0s => CACHED [ 2/10] RUN apt-get update -qq && apt-get install -y build-essential nodejs && rm -rf /var/lib/apt/lists/* 0.0s => CACHED [ 3/10] RUN gem install bundler 0.0s => CACHED [ 4/10] WORKDIR /tmp 0.0s => CACHED [ 5/10] ADD Gemfile Gemfile 0.0s => CACHED [ 6/10] ADD Gemfile.lock Gemfile.lock 0.0s => CACHED [ 7/10] RUN BUNDLER_VERSION=2.1.2 bundle install 0.0s => CACHED [ 8/10] RUN mkdir -p /myapp 0.0s => CACHED [ 9/10] WORKDIR /myapp 0.0s => CACHED [10/10] ADD . /myapp 0.0s => exporting to image 0.0s => => exporting layers 0.0s => => writing image sha256:c57dc4b7785a80ee5b1a6c2086bda32e5ed8f009d69648a18b0f6ef045ca7400 0.0s => => naming to docker.io/library/everydayrails-rspec-2017_web 0.0s Use 'docker scan' to run Snyk tests against images to find vulnerabilities and learn how to fix them 今回遭遇したエラーというのが、このbuildを行なった時に出たエラーとなります。 エラー文 ### 省略します => CACHED [ 4/10] WORKDIR /tmp 0.0s => CACHED [ 5/10] ADD Gemfile Gemfile 0.0s => CACHED [ 6/10] ADD Gemfile.lock Gemfile.lock 0.0s => ERROR [ 7/10] RUN bundle install ------ > [ 7/10] RUN bundle install: #11 0.555 You must use Bundler 2 or greater with this lockfile. ------ executor failed running [/bin/sh -c bundle install]: exit code: 20 ERROR: Service 'web' failed to build : Build failed bundle installを走らせた時にエラーが発生しているようです。 gemfile.lockにはbundlerのバージョン2を使う必要があるとのことです。 ですが、私の環境ではbundlerは2以上を使っていました。 確認方法としては、 gem list bundler で現在インストールされているものをリストアップ Gemfile.lockの一番下にある　BUNDLED WITHを見る これらを行うことでbundlerのバージョンを見ることができます。 バージョンを指定して、bundle installを実行する際には ターミナル bundle _1.16.6_ install と打つことで`1.16.6_を用いてbundle installができます。 ちょっと脱線しましたが、本題に戻ります。 私の環境では、bundlerを2以上で作成しているのにエラーでは2以上がいると怒られています。 ここで対処法としていくつか考えました。 1.バージョンを下げてみる 2.「BUNDLER_VERSION=2.1.2 bundle install」を実行する 3.バージョンを2で指定してみる これくらいしか思いつきませんでした。 それぞれ実行してみると、、、、、、、 2の手順でエラーに変化がありました。 requires ruby version >= 2.6, which is incompatible という文に変わり、rubyのバージョンを2.6以上にしないといけないようです。 なので、dockerファイルのFROMの部分を書き換えます。 FROM ruby:2.7 としてください。 これでbuildができました。 次はdocker-composeの中でbundle installを走らせます。 docker-compose run web bundle install その後 コマンド docker-compose up を入力してください これでlocalhost:3000にアクセスすることで表示されるはずなのですが、実際にアクセスしてみると、エラーになるはずです。 おそらく、databaseが無いと怒られます。私がそうでした。 これを解消するには、 rails db:create rails db:migrate の2つを実行して、databaseを作成しないといけません。 ただこのコマンドを打つだけでは、コンテナの外で実行していることになるので、ちょっとコマンドを追加しないといけません。 docker-compose exec web rails db:create docker-compose exec web rails db:migrate これで何のエラーもなくデータベースが作成されたら成功です! localhost：3000にアクセスすると正常に動くはずです。 まとめ bundlerのエラーが出た時は、バージョンを落とすか上げる。 Gemfile.lockを削除して再度bundle installを実行する 必要に応じてrubyのバージョンも上げること エラー文をよく読むこと 以上です!!

記事の概要 Dockerコンテナ内にあるデータのライフサイクル（寿命）は、コンテナのライフサイクルと共にあります。 通常、Dockerボリュームなどを使い、データのライフサイクルはコンテナのライフサイクルと分離します。 ただし、Dockerボリューム内に蓄積されたデータも何らかの障害で失われる可能性や過去の状態に戻したい場合があります。 Dockerボリュームのライフサイクルとは別に、バックアップを取得して第3のライフサイクルとして管理しておくと安心です。 この記事では、OSのディレクトリ上へDockerボリューム内にあるファイルをバックアップする方法について説明します。 またDropbox APIを使って、取得したバックアップファイルをDropboxへ保管する方法についても解説します。 前提条件 本手順の検証は以下の環境で行いました。 OS：CentOS7 Docker：ver19.03.13 また、Dropbox APIを使用するため、Dropboxアカウントが必要になります。 Dockerボリューム内にあるファイルをバックアップする 以下のdocker runコマンドを実行することで、Dockerボリューム内にあるファイルをOS上のディレクトリにバックアップできます。 docker run \ --rm \ --volumes-from [バックアップ対象のコンテナ名] \ -v [バックアップ先となるOSのファイルパス]:/backup \ busybox cp [コンテナ内のバックアップ対象のファイルパス] /backup/[バックアップファイル名] --rm： 　このオプションはコンテナの終了時に、コンテナが使用しているファイルシステムを削除します。 　バックアップ用のコンテナなので、用が済んだら後片付けを行います。 --volumes-from [バックアップ対象のコンテナ名]： 　このオプションではバックアップ対象のコンテナにマウントされているDockerボリュームを、バックアップ用のコンテナ（ここではbusybox）にマウントします。 　例えば、appコンテナの/var/www/app/dataにDockerボリュームをマウントしている場合、busyboxコンテナの/var/www/app/dataにDockerボリュームがマウントされます。 -v [バックアップ先となるOSのファイルパス]:/backup： 　このオプションではバックアップ先となるOSのファイルパスを、バックアップ用のコンテナの/backup（ここではbusybox）にマウントします。 　例えば、OSのファイルパスとして/home/hogehoge/app/dataを指定すると、/home/hogehoge/app/dataがbusyboxコンテナの/backupにマウントされます。 busybox cp [コンテナ内のバックアップ対象のファイルパス] /backup/[バックアップファイル名]： 　このコマンドは、バックアップしたいファイルを、OS上のディレクトリにコピーするために実行します。 　例えば、コンテナ内のファイルパスとして/var/www/app/data/db.sqlite3を指定し、バックアップファイル名としてdb.sqlite3を指定すれば、/backup/db.sqlite3（/backupにはOS上のディレクトリがマウントされている）へ/var/www/app/data/db.sqlite3がコピーされます。 DropboxへAPIを使ってファイルをアップロードする Dropboxは無料でも使用可能なクラウドストレージです。 また、同一のファイル名は30日間だけ遡って、復元することもできます（つまり30日バージョン管理として使えます）。 バージョン履歴はストレージ容量にカウントされないため、容量節約にもなります。 バージョン履歴はストレージ容量にカウントされますか？ いいえ、バージョン履歴はストレージ容量には含まれません。 バージョン履歴の概要 ここでは上記の特徴から、ファイル名を同一のものにして、バックアップのたびに上書きするようにします。 Dropbox App consoleへログイン 以下のURLへアクセスします。 https://www.dropbox.com/login?cont=https%3A%2F%2Fwww.dropbox.com%2Fdevelopers%2Fapps%3F_tk%3Dpilot_lp%26_ad%3Dtopbar4%26_camp%3Dmyapps appを作成 画面右上にあるCreate appを選択します。 1. Choose an API：Scoped access 2. Choose the type of access you need：App folder（このappのためのフォルダを作り、そこだけにアクセスさせます。） 3. Name your app：好きなappの名前を入力します。 Create appボタンを選択して作成します。 appのパーミッションを設定 作成されたappを選択後、Permissionsタブを開きます。 アップロードに必要なfiles.content.writeにチェックを入れます。 ここでは、files.content.readにもチェックを入れていますが、不要であれば、入れなくて大丈夫です。 画面下部にあるSubmitボタンを押します。 アクセストークンの発行 Settingsタブに戻り、アクセストークンを作成します。 Access token expirationをShort-livedにすると短い間だけ有効になります。 No expirationは無期限です。 どちらかを選択した後で、Generated access tokenのGenerateボタンを選択します。 以下のような文字列が生成されるため、コピーして保管します（ページ遷移すると消えるため）。 sl.A9KVBrdIBMTHy1tyM6vUi3KMKHrh_LFJhX-ygxkgzprNyF6q19hdPksEjgzQ_7YSMcBzha7xruUug1RjvbAlzuinAyAfeguvOqj1j5HlLPR0MAzntJTgsS_JZnhogehogehoge Dropbox API Explorerでアップロード検証 以下のURLに接続してDropbox API Explorerを開きます。 https://dropbox.github.io/dropbox-api-v2-explorer/#files_upload File to uploadにテスト用のファイルを選択します。 pathは/test.txtのように/にファイル名（アップロード先のファイル名）を結合したものです。 mode(optional)はoverwriteを選択します。 Submit Callボタンを押して正常にアップロードされることを確認します。 実際にDropboxの画面を開くと、アプリフォルダが作成されていて、前の手順で作成したapp名のフォルダが作られています。 アプリ 　= app名（pathで指定するときのルートフォルダ、つまり/） 　　= hogehoge.txt curlで実行できるようにする。 Dropbox API Explorer内でShow Codeボタンを押すと、実際に実行するコードを参照できます。 以下は例です。 curl -X POST https://content.dropboxapi.com/2/files/upload \ --header 'Authorization: Bearer ZTZ-m7zw48MAAAAAAAAAAZ5Ps8hDrpTPI37W3Ocfgc1LmB3Hu0hogehogehoge' \ --header 'Content-Type: application/octet-stream' \ --header 'Dropbox-API-Arg: {"path": "/test.txt", "mode":{".tag":"overwrite"}}' \ --data-binary @'hogehoge.txt' 自分の環境でShow Codeを実行した後で、下2行を変更します。 --header 'Dropbox-API-Arg: {"path": "Dropboxのファイルパス（ファイル名を入れる）", "mode":{".tag":"overwrite"}}' \ --data-binary @'Dropboxへアップロードするクライアントのファイルパス' 例えば、Dropboxのアプリ - test（testはapp名）配下にOS上の/home/hoge/hogehoge.txtをdropbox_hogehoge.txtという名前でアップロードするには、 --header 'Dropbox-API-Arg: {"path": "/dropbox_hogehoge.txt", "mode":{".tag":"overwrite"}}' \ --data-binary @'/home/hoge/hogehoge.txt' とします。 実行できる形になったら、OS上から実行して正常にアップロードされるかを確認します。 cronを使って定期実行させる このままでも手動で実行は可能ですが、cronを使って毎日実行する例を記載します。 非rootユーザー dockerコマンドを実行できるユーザー（dockerグループに所属）で実行しています（rootではない）。 crontab -eで編集画面へ移動し、以下を書き込みます。 SHELL=/bin/bash 00 18 * * * docker run --rm --volumes-from container -v /home/hogehoge/backup/data:/backup busybox cp /backup_file_in_container/fugafuga /backup/backup_`date +\%Y\%m\%d` 00 19 * * * upload_to_dropbox.sh 00 20 * * * rm /home/hogehoge/backup/data/backup_`date --date '7 days ago' +\%Y\%m\%d` 18時に実行しているのは、コンテナ内にあるファイルをバックアップするコマンドです。 ここでは日付をファイル名に付けています。 19時はDropboxへファイルをアップロードするスクリプトを実行します。 先程のcurlコマンドをスクリプトファイルに入れただけです。 upload_to_dropbox.sh file_name="/home/hogehoge/backup/data/backup_`date +%Y%m%d`" curl -X POST https://content.dropboxapi.com/2/files/upload \ --header 'Authorization: Bearer ZTZ-m7zw48MAAAAAAAAAAZ5Ps8hDrpTPI37W3Ocfgc1LmB3Hu0hogehogehoge' \ --header 'Content-Type: application/octet-stream' \ --header 'Dropbox-API-Arg: {"path": "/test.txt", "mode":{".tag":"overwrite"}}' \ --data-binary @${file_name} 20時に、OS上のバックアップファイルを削除します。 念の為、OS上にも7日分のバックアップファイルを保持しておきたいので、7日前のものを削除します。 rootユーザー 人にもよりますが、私が運用している環境はコンテナからバックアップしたファイルの所有者がrootになっています。 このままだと、root以外のユーザーでファイルを消せないので、所有者を変更します。 rootユーザーでcrontab -eを実行し、以下を書き込みます。 30 18 * * * chown hogehoge:hogehoge -R /home/hogehoge/backup/data/ 最後にDropboxへのアップロードが正常に行われたかどうかの通知をSlackで受け取ります。 後日執筆予定。 参考 Backup a container Dockerコンテナのバックアップ方法について記載あり Dropbox API v2 APIドキュメント APIを利用する場合は上記ドキュメントと合わせてExploreも使用すると楽になる。 Dropbox API Explorer

前提 Windows環境 「c:\usr\webapps」にWARを配置しておく。 コマンド Jetty 最新版を利用する場合 docker run --rm -it -p 8000:8000 -p 8080:8080 -v c:/usr/webapps:/var/lib/jetty/webapps jetty Tomcat 9.0 を利用する場合 docker run --rm -it -p 8000:8000 -p 8080:8080 -v c:/usr/webapps:/usr/local/tomcat/webapps tomcat:9.0 以上。

備忘 DooD(Docker outside of Docker)環境Jenkins 環境 Fedora Linux 35 (Workstation Edition) Docker version 20.10.9, build c2ea9bc dockerデーモンは起動済み 操作ユーザーはdocker groupに属する (sudo usermod -aG docker $USER) jenkins_home は操作ユーザーの $HOME/jenkins_home とする 環境構築 Dockerfile 明瞭さを優先し、jenkins/jenkinsにget-docker.shを用いてdockerを導入 Dockerfile FROM jenkins/jenkins USER root RUN curl -fsSL https://get.docker.com -o get-docker.sh && sh get-docker.sh && rm get-docker.sh USER jenkins docker build および docker run $ mkdir $HOME/jenkins_home $ docker build . -t jenkins-dood ... $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE jenkins-dood latest b07c3629294e 21 hours ago 944MB jenkins/jenkins 2.322-jdk11 a7aa4a28243e 4 days ago 442MB jenkins/jenkins latest a7aa4a28243e 4 days ago 442MB $ docker run -d \ --name jenkins-dood \ -u $(id -u):$(id -g) \ --group-add $(awk -F: '$1 == "docker" {print $3}' /etc/group) \ -v $HOME/jenkins_home:/var/jenkins_home \ -v /var/run/docker.sock:/var/run/docker.sock \ -p 8080:8080 \ -p 50000:50000 \ jenkins-dood $ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6b38450bc7dd jenkins-dood "/sbin/tini -- /usr/…" 12 seconds ago Up 11 seconds 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp jenkins-dood $ docker logs jenkins-dood # 初期キーフレーズ確認などのため ... podmanへの置き換えの可能性を考慮し、docker-composeの利用は一旦保留。 http://localhost:8080 にアクセスすることでJenkins管理画面に接続可能 コンテナ内からdockerコマンドが使用可能であることの確認 $ docker exec -it jenkins-dood /bin/bash jenkins@6b38450bc7dd:/$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6b38450bc7dd jenkins-dood "/sbin/tini -- /usr/…" 2 minutes ago Up 2 minutes 0.0.0.0:8080->8080/tcp, :::8080->8080/tcp, 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp jenkins-dood jenkins@6b38450bc7dd:/$ exit exit $ 課題1: jenkins_homeのパーミッション Jenkinsの設定などがおかれるjenkins_homeは、ローカルとシェアして永続化する。 docker run時、デフォルトではコンテナ内ではuidが1000のjenkinsユーザーとなる為、作成されるjenkins_home内のファイルもuid 1000となる。 これでは使い勝手が悪い為、docker run時に、-u \$(id -u):\$(id -g)オプションを指定し、jenkins_home内のファイルの所有者、所有グループをコマンド実行ユーザーに合わせる。 課題2: /var/run/docker.sock へのアクセス許可 コンテナ内からもdockerを使えるようにする為、/var/run/docker.sockを共有させている。 外の/var/run/docker.sockは、所有グループのdockerグループに対する権限許可によりアクセスを可能としている。 $ ls -l /var/run/docker.sock srw-rw---- 1 root docker 0 Nov 27 10:18 /var/run/docker.sock コンテナ内のプロセスも/var/run/docker.sockへのアクセスの為には、外のdockerグループのgidのグループに参加させる必要がある為、docker run時に、--group-add \$(awk -F: '\$1 == "docker" {print \$3}' /etc/group) オプションを指定する。 $()内の以下は、/etc/groupから、:区切りの第1項目がdockerの行の第3項目を出力する awk -F: '$1 == "docker" {print $3}' /etc/group 参考資料 Install using the convenience script その後の参照資料 Using Docker with Pipeline Pipeline Syntax 爆速でJenkinsをマスターしよう(Docker編) ~ JenkinsコンテナへのDockerインストール方法からJob DSL、Jenkins Pipelineまで ~ Jenkinsジョブ（ビルド～テスト）をDockerコンテナ上で実行する ～Docker Pipeline Pluginを使ってみる～ Jenkinsを使った自動テスト環境を作る（後編）――Dockerコンテナを使って自動ビルドを実行する

login Dokerアカウントにログインするコマンド $ docker login 【docker for mac or docker for windowsをご使用の場合】 dockerアイコンをクリック sign in/Create Docker IDをクリック Docker IDとパスワードの入力でログイン可能 run dockerイメージからdockerコンテナ一つを起動するコマンド $ docker run <イメージ名> よく使うオプション --name コンテナに任意の名前を付ける $ docker run --name <任意の名前> <イメージ名> -d コンテナをバックグランドで動作させる $ docker run -d <イメージ名> -p ホスト上のポートをコンテナ内のポートとマッピング（ポート指定） # 構文 $ docker run -p <ホストポート：コンテナポート> <イメージ名> # ホスト上の3000番ポートをコンテナ内の80番ポートとマッピングして起動する場合 $ docker run -p 3000:80 docker-image --rm プロセスが終了したコンテナを削除 $ docker run --rm <コンテナ名> <イメージ名> -v コンテナにボリュームをマウントして共有するオプション $ docker run -v <ホストのパス:コンテナのパス> <イメージ名> ps 起動中のコンテナ一覧を表示するコマンド 停止中のコンテナは表示されない。表示したい場合は、-aオプションを付ける必要がある # 構文 $ docker ps # 停止中のコンテナ一覧も表示 $ docker ps -a コンテナの操作 コンテナは、コンテナID、もしくはコンテナ名で指定 コンテナ一つを操作する いずれのコマンドも削除はせず、コンテナは残る start dockerコンテナを起動するコマンド $ docker start <コンテナ名> stop dockerコンテナを停止するコマンド $ docker stop <コンテナ名> restart dockerコンテナを再起動するコマンド $ docker restart <コンテナ名> exec 起動中のコンテナ内でコマンドを実行 起動中のコンテナに入らずコマンドを実行 -itオプションを使うとコンテナに入ることができる # 構文 $ docker exec -it <コンテナ名> /bin/bash # 出力結果 [root@<コンテナID>/]# # 終了コマンド $ exit rm 停止中のコンテナを削除するコマンド 注意点 起動中のコンテナは削除することができない コンテナ内のデータも消えるので注意！ $ docker rm <コンテナ名> # 起動中のコンテナを削除する場合 $ docker rm -f <コンテナ名> images ローカルにあるイメージを全て表示するコマンド $ docker images rmi Dokerイメージを削除するコマンド 注意点 起動中コンテナのイメージは削除できない Dockerイメージには依存関係があるので、ベースとなるイメージは削除できない $ docker rmi <イメージ名> build Dockerfileからイメージを生成するコマンド Dockerfileのパス名はディレクトリ名のみの指定でOK $ docker build <Dockerfileのパス名> -t 作成するDockerイメージのイメージ名およびタグ名を指定するオプション $ docker build -t <イメージ名:タグ名> <Dockerfileのあるディレクトリ名> cp コンテナとホストマシンでファイルのやりとりを行うコピーコマンド ログファイルや設定ファイルの取り出しや入力で使用 コマンドの実行はホスト側から行う # ホストからコンテナをコピーする場合 $ docker cp <ホストファイルのパス>　<コンテナ名>:<コンテナのパス> # コンテナからホストへコピーする場合 $ docker cp <コンテナ名>:<コンテナのパス> <ホストファイルのパス> logs Dockerコンテナのログ出力するコマンド 原因不明のコンテナ停止やアクセスログを確認する時に使用 # 構文 $ docker logs <コンテナ名> # リアルタイムでログを確認する場合 $ docker logs -f <コンテナ名> 参考教材

docker-composeとは YAMLファイルという形式の設計図で、複数コンテナをまとめて管理することができるDockerアプリケーションのためのツール YAMLファイルとは スペースで親子関係を表現するファイル形式のことで設定ファイルなどによく使われる ネストが入ったら子供関係(web(親)とbuild(子)） 並列が入ったら並列関係（webとdb） docker-compose.yml version: "3" services: web: build: ./php db: image: mariadb: 10.4 image or build コンテナイメージを指定する項目のこと image DockerHubから指定 build DockerfileからDockerイメージを作成 Docker-compose.ymlから見たパスを相対パスで指定 下記コードでは、Dockerfileが同じ階層にあることを指している docker-compose.yml version: "3" services: web: build: ./php db: image: mariadb: 10.4 container_name コンテナに任意の名前を付けるコマンド docker run --nameとやっていることは一緒 任意のコンテナ名を付けることができる コンテナ名はダブルクォーテーションで囲う 分かりやすい名前を付けることでコンテナの指定が容易になる docker-compose.yml web: build: ./php container_name: "php8" db: image: mariadb: 10.4 container_name: "db2" volume コンテナとホストのディレクトリを共有する命令 docker run -vとやっていることは一緒 コードや設定ファイルに使用する ホスト側は相対パスがオススメ 絶対パスだとユーザー名の部分を書き換える必要がある docker-compose.yml # 構文 　volume: <ホストのパス>:<コンテナのパス> # db: volume: ./data:/var/lib/mysql ports コンテナのポート開放とポートフォワーディングを行うオプション docker run -pとやっていることは一緒 ポートが被らないように指定できる 複数のポートが被ると立ち上げられないため、そのような場合は、外部公開ポートを指定する必要がある portsの後に改行し、ネストをふやした後でダブルクォーテーションで囲って記述する必要がある docker-compose.yml # 構文 　ports: <外部公開ポート>:<コンテナ内部ポート> # 具体例 web: image: php:8.0 ports: "8080:80" db: up コンテナを起動するコマンド イメージが作成されていない場合、イメージ作成後にコンテナを作成・起動 すでにコンテナが存在する場合、イメージ・コンテナの再作成は行わず、停止中のコンテナを起動 $ docker-compose up -d コンテナをバックグラウンドで起動するオプション そのため、同ターミナルでコマンド操作が可能 $ docker-compose up -d --build Dockerfileの書き換えなどのビルド処理の変更をイメージに反映させるオプション $ docker-compose up --build down docker-compose.ymlで管理されているコンテナをストップ＆削除する カレントディレクトリのdocker-compose.ymlのみ適用される 同じ階層にdocker-compose.ymlがない場合は上の階層を探しに行く $ docker-compose down restart docker-compose.ymlで管理されているコンテナをすべて再起動する $ docker-compose restart ps docker-compose.ymlで管理しているコンテナ一覧の表示 対象のdocker-compose.ymlで書かれたコンテナのみ表示されるのでコンテナを把握しやすくなる $ docker-compose ps run docker-compose.ymlで管理しているサービス一つを指定してコマンドを実行 build前でも実行可能なコマンドで、フレームワークのインストールなどに使うと便利 $ docker-compose run <サービス名> <実行したいコマンド>

TeXでソースコードをVSCode風に出力してみた そこまでTeXに詳しいわけではないですが，調べたりして実際にレポートで書いたので載せる． 前回の記事より細かく書いてみた 目次 PC環境 TeX環境 使用したTexの文章クラス ソースコードの出力に使用するパッケージ plistingsについて listingsによる言語定義 lstsetによる言語設定 VSCode風に色設定 プログラムを出力 おまけキャプション変更と参照コマンドの定義 PC環境 環境 PC M1 Macbook Air OS Big Sur インストール場所 Docker TeX環境 Docker上でPaperist/texlive-jaのlatestのバージョンをイメージをpullする． githubにもある． 使用したTexの文章クラス 文章クラス(documentclass)にはjsarticleを使用した． jsarticleは新しい和文に対応した文章クラスである． 次に使用例を示す． \documentclass[a4j,uplatex,dvipdfmx,11pt]{jsarticle} オプションについては次の表に示す． オプション 使用理由 a4j 日本のA4サイズ uplatex コンパイラの種類(?) dvipdfmx PNG画像の読み込みと色設定に使用 11pt 標準の文字の大きさ ソースコードの出力に使用するパッケージ listingsはソースコードを掲載するのに，便利なもの． 日本語を対応させるために，plistingsも読み込む． plistingsについては次のセクションで説明する． VSCode風に出力するために，colorを読み込む． \usepackage{listings,plistings} \usepackage{color} plistingsについて 先のTeX環境の記述したPaperist/texlive-jaにはplistingsが入ってない． Docker初心者なので，dockerfileの書き換えなど詳しいことはわからないので， 今回は，texファイルと同じディレクトリ内にplistings.styを置いた． listingsによる言語定義 \lstdefinelanguage{<言語名>}{<設定>} を使って新しい言語として設定する． 先に設定について次の表に示す． キー名 意味 値 オプション オプションの意味 morekeywords キーワードを追加 {key1, key2, ...} [<数字>] キーワードを区別 sensitive 大文字小文字の区別 true or false morecomment コメントアウトとなる記号の追加 {<記号>} [l] or [s] lは1行(左に位置する), sは複数行(囲われている) morestring 文字列となる記号の追加 {<記号>} [b] or [d] bはバックスラッシュまで, dは2つ続くまで alsodigit 記号を数字に追加 {<記号>} alsoletter 記号を文字に追加 {<記号>} ． 今回のプログラミング言語はScilabで作成した． morekeywordsのオプションで役割を決めた． 出力したいプログラムの中にある予約語や関数名などを追加していく． オプションの数字によって分けているため，分け方は自由． オプション 役割 1 予約語 2 関数名 3 大域変数 4 定数 実際に書いたTeXファイルの言語定義の部分を次に示す． 上の表に従って作成した． また，定数が\%piのように\%が必要なので，alsoletterに\%を追加する． \lstdefinelanguage{myscilab}{ morekeywords=[1]{ % 予約語 標準ライブラリを含む for, end, if, then, function, endfunction, clear, strtod, read_csv, size, zeros, mean, sqrt, floor, string, disp, sum, cov, cell, cat, exp, matrix, inv, det, int, gsort, tabul, max, }, morekeywords=[2]{ % 関数名 get_class_range, bayes_train, bayes_valid, }, morekeywords=[3]{ % 大域変数 DATADIR, ALLDATA, FEATURE1, FEATURE2, FEATURES, FDIM, FDATA, ALLDATA, N_CLASS, N_FDATA, N_CLASS_DATA, }, morekeywords=[4]{ \%inf, \%pi, }, % 定数 sensitive=true, % 大文字小文字の区別 morecomment=[l]{//}, % コメントアウト morestring=[d]{'}{'}, % 文字列 (シングル) morestring=[b]{"}, % 文字列 (ダブル) alsoletter={\%}, % 文字としてに\%を追加 } lstsetによる言語設定 lstsetによる言語設定に示す． 下の方で予約語などの文字のスタイルを指定している． colorについては後述する． \lstset{ language=myscilab, % 新しく定義した言語を設定 frame=none, % 枠設定 breaklines=true, % 行が長くなった場合自動改行 breakindent=12pt, % 自動改行時のインデント columns=fixed, % 文字の間隔を統一 basewidth=0.5em, % 文字の横のサイズを小さく numbers=left, % 行数の位置 numberstyle={\scriptsize \color{white}}, % 行数のフォント stepnumber=1, % 行数の増間 numbersep=1zw, % 行数の余白 xrightmargin=0zw, % 左の余白 xleftmargin=2zw, % 右の余白 framexleftmargin=18pt, % フレームからの左の余白 keepspaces=true, % スペースを省略せず保持 lineskip=-0.2ex, % 枠線の途切れ防止 tabsize = 4, % タブ数 showstringspaces=false, %文字列中の半角スペースを表示させない %%%%% VSCode風 の style & color %%%%% backgroundcolor={\color[gray]{0.1}}, %背景色 basicstyle ={\small\ttfamily \color{white}}, % 基礎の文字のフォント設定 identifierstyle={\small \color{identifier}}, % 変数名などのフォント設定 commentstyle ={\small \color{comment}}, % コメントのフォント設定 keywordstyle =[1]{\small\bfseries \color{keyword1}}, % 予約語のフォント設定 keywordstyle =[2]{\small\bfseries \color{keyword2}}, % 関数名のフォント設定 keywordstyle =[3]{\small\bfseries \color{keyword3}}, % 大域変数のフォント設定 keywordstyle =[4]{\small\bfseries \color{keyword4}}, % 定数のフォント設定 stringstyle ={\small\ttfamily \color{string}}, % 文字列のフォント設定 %%%%% VSCode風 の style & color %%%%% } VSCode風に色設定 VSCodeのデフォルトの配色風に色設定してみた． definecolorの1つ目の中括弧で色の名前を定義するが，今回は上のlstsetの文字のスタイルの指定にある colorのものに対応する形で作成した． \definecolor{identifier}{rgb}{0.611, 0.862, 0.996} % LightBlue (変数) \definecolor{comment}{rgb}{0.415, 0.600, 0.333} % DeepGreen (コメント) \definecolor{keyword1}{rgb}{0.768, 0.521, 0.749} % Purple (予約語) \definecolor{keyword2}{rgb}{0.862, 0.862, 0.666} % Yellow (関数名) \definecolor{keyword3}{rgb}{0.2, 0.8, 1} % Blue (大域変数) \definecolor{keyword4}{rgb}{0.854, 0.439, 0.839} % Pink (定数) \definecolor{string}{rgb}{0.847, 0.560, 0.458} % Orange (文字列) プログラムを出力 プログラムファイルの出力の仕方は2つある． 1つ目 \begin{lstlisting}[language=<言語名>, caption=<キャプション>, label=<ラベル>] ... ... ... \end{lstlisting} 2つ目 \lstinputlisting[language=<言語名>, caption=<キャプション>, label=<ラベル>]{<ファイルパス>} 出力結果 (おまけ) キャプション変更と参照コマンドの定義 \newcommand{\lstlistingnameref}[1]{\textbf{Source Code.\ref{#1}}} % ソースコード参照 \renewcommand{\lstlistingname}{\textbf{Source Code.}} % ソースコードキャプション

前提条件 OS MacOS Monterey 12.0.1 CPU Apple M1(arm64) Docker Docker Desktop 4.2.0 (70708) CentOS CentOS Linux release 7.9.2009 (AltArch) やりたいこと 記事名のとおりです。 手順 １　M1MacBookにDockerをインストール Docker desktopをインストールします。 （M1をお使いの場合は、Apple chipの方をインストールしてください） ２　Dockerデーモン起動のためのコマンドをMacのターミナルに入力 （中央に示されたコマンドをコピペします） % docker run -d -p 80:80 docker/getting-started Dockerデーモンが起動すると思います。 ⇨イメージ名「docker/getting-started」を用いたコンテナを新規作成してます。 【コマンド詳細（オプション）】 -d： コンテナーをデタッチ（detached）モード、つまりバックグラウンドで実行し、コンテナIDを付与します。 --detach Run container in background and print container ID -p 80:80： ホストの 80 ポートをコンテナーの 80 ポートにマッピングします。 -p, --publish list Publish a container's port(s) to the host ３　Docker HubからCentOS7のイメージを取得（pull） % docker pull centos:centos7 ●イメージ取れたことを確認 % docker images REPOSITORY TAG IMAGE ID CREATED SIZE centos centos7 dfc30428e163 8 weeks ago 301MB docker/getting-started latest 613921574f76 5 months ago 26.7MB ①docker desktopを起動したときに使ったdocker/getting-startedのイメージと、 ②先ほどpullしたCentOSのイメージ 　　の２つがきちんと取得できていることが分かります。 ４　取得したイメージを使ってコンテナを作成 % docker run -it -d --name centos7 centos:centos7 【コマンド詳細（オプション）】 -nameオプションはそのまま、コンテナにCentOS7という名前をつけるために使っています。 オプションの「-it」の意味は下記。 【-iオプション】 Dockerホストとコンテナ内のシェルを接続したままにする -i, --interactive Keep STDIN open even if not attached ※interactive=対話、相互作用 ※STDIN＝標準入力 【standard input】 【-tオプション】 コンテナ内のシェルが使用するttyを割り当てる -t, --tty Allocate a pseudo-TTY 　Allocate＝割り当てる 　pseudo＝擬似 　⇨コンテナで構築したCentOSのシェル（bash）へ擬似的に端末を割り当てる？という意味合いかと思います（すいません、上手く表現できません。。。） 【-dオプション】 前述の通りです。 % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0a412e1af0a1 centos:centos7 "/bin/bash" 8 seconds ago Up 8 seconds centos7 6a588ccfd4cf docker/getting-started "/docker-entrypoint.…" 29 minutes ago Up 29 minutes 0.0.0.0:80->80/tcp quirky_carson ↑作成したコンテナが起動したことを確認。 起動中のコンテナを一覧表示（List containers）するコマンドです。 ※psコマンドは Linuxコマンドにおいて「Process Status」（実行中のプロセス表示）の意味で登場します。 ５　作成したCentOSコンテナ内でLinuxコマンドを使えるようにする コンテナが無事起動したら、CentOSを動かせるようにします。 docker exec -it centos7 /bin/bash ※ exec=execute（実行する） 【docker exec】 docker execコマンドは、指定したコマンドやスクリプトなどを、指定したコンテナ内部で起動することができます。 exec Run a command in a running container 　　（起動中のコンテナ内でコマンドを実行する） 　⇨ここでは、CentOSのコマンドを実行できるようにする、ということですね。 オプションの「-it」の意味は前述の通りです。 【centos7 /bin/bash】 コンテナ名　/ コマンド ※コマンドは、上記docker -psの時にCOMMANDとして出力されています 初回はここまでの手順を踏むことで、CentOS環境が構築できます。 ６　次回以降の起動 1.Docker desktopを起動 2.Macターミナルにて、 docker start centos7 CentOS７コンテナが起動するので、初回同様、rootユーザとして CentOSのシェルにコマンドを叩けるようにします。 docker exec -it centos7 /bin/bash ありがとうございました。 補足 Macのターミナルで docker --help docker run --help と入力すれば、オプションなどのコマンドの詳細が得られます。全て英語で読みづらいですが、ネットに転がっている情報は色んな解釈や加工がされている可能性がある分、--helpで呼び出せる情報が最も正確だと言えるかもしれません。 各手順で入力したコマンドの詳細（英文のところ）などは、helpコマンドから抜粋しながら書いてます。 （今回登場したオプションを抜粋） (docker) -ps List containers -pull Pull an image or a repository from a registry -start Start one or more stopped containers -exec Run a command in a running container （docker run） -d, --detach Run container in background and print container ID -p, --publish list Publish a container's port(s) to the host (docker exec) -i, --interactive Keep STDIN open even if not attached -t, --tty Allocate a pseudo-TTY 注意点 上記手順でCentOS環境を作ると、rootユーザーでログインした状態になります。 参考サイト