Docker

適当に検索すると、ホストへの特権昇格を許す設定ばかり見かける。 自分だけしか使わないならば構わないかもしれないけれど、なんらかのCIを実行する権限さえあれば、ホストのroot権限をとれるというのは危険だと思う。 （コードレビュー必須でPRではマージ済みのCIが実行されるならいいのか…？） GitLabの公式Shared Runnerがやっているように、docker-machineを使うのがいいはず。 おそらくdocker入りの仮想マシンをCIジョブごとに立てて、privilegedなコンテナからブレイクアウトしても仮想マシンの外に出られないようになっていると思う。 GitLabはいろいろオープンなので、実際のShared Runnerの構成・設定が公開されている。たいへん助かる。 https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html のだけれども、GCPでこれを稼働させるのはちょっと費用面がよくわからない…。 ツリー https://twitter.com/aoirint/status/1523826104343343105 https://twitter.com/aoirint/status/1524426103615500288

ビルドコマンド https://stackoverflow.com/questions/58592259/how-do-you-enable-buildkit-with-docker-compose DOCKER_BUILDKIT=1 COMPOSE_DOCKER_CLI_BUILD=1 docker-compose build Dockerfile https://www.docker.com/blog/introduction-to-heredocs-in-dockerfiles/ # syntax=docker/dockerfile:1.3-labs

https://github.com/aoirint/webdav-docker https://hub.docker.com/r/aoirint/webdav 以下のリポジトリをforkし、Windows 10のExplorerクライアントに対応させたDockerイメージ。 Apache Web ServerのDAV機能でWebDAVサーバを立てる。 https://github.com/BytemarkHosting/docker-webdav docker-compose.yml version: '3.9' services: webdav: image: aoirint/webdav:2.4-20210822c restart: always ports: - '${DAV_PORT:-127.0.0.1:8000}:80' environment: LOCATION: /webdav ANONYMOUS_METHODS: OPTIONS AUTH_TYPE: Basic USERNAME: ${DAV_USERNAME:-user} PASSWORD: ${DAV_PASSWORD:-password} # SKIP_CHOWN: 1 volumes: - ./dav:/var/lib/dav 以上の設定で、dav://127.0.0.1:8000/webdavにWebDAVサーバが立つ。 データは./dav/dataに格納される。 Optional: /etc/fstab シンボリックリンクは動作しないので、bindfsを使う。 sudo apt install bindfs fuse-utils /src/path /dest/dav/data/path fuse.bindfs rw,user,uid=YOURUSER 0 0 https://www.netfort.gr.jp/~tosihisa/notebook/doku.php/bindfs

https://hub.docker.com/r/dperson/smokeping Copy Configs docker run --name smokeping --rm -d dperson/smokeping:latest docker cp smokeping:/etc/smokeping ./config docker rm -f smokeping docker-compose.yml version: '3.9' services: smokeping: image: dperson/smokeping:latest restart: always ports: - '{SMOKEPING_PORT:-127.0.0.1:8000}:80' volumes: - './config:/etc/smokeping:ro' - './data:/var/lib/smokeping' environment: TZ: Asia/Tokyo config/config.d/Targets *** Targets *** probe = FPing menu = Top title = Network Latency Grapher remark = Welcome to the SmokePing website of xxx Company. \ Here you will learn all about the latency of our network. + Home menu = Home title = Home Network #parents = owner:/Test/James location:/ ++ Router menu = Router (192.168.0.1) title = Router (192.168.0.1) host = 192.168.0.1 ++ MyServer menu = MyServer (192.168.0.2) title = MyServer (192.168.0.2) host = 192.168.0.2 #alerts = someloss

https://github.com/Pryaxis/TShock https://hub.docker.com/r/ryshe/terraria/ 上記URLから最新（もしくは対応する）バージョンを確認して、イメージタグのバージョンを変更する。 既存のワールドを使用する場合は、./data/worlds/に.wldファイルを配置し、WORLD_FILENAMEを変更する。 docker-compose.yml version: '3.9' services: terraria: image: ryshe/terraria:tshock-1.4.2.3-4.5.5 tty: true stdin_open: true restart: always ports: - '7777:7777' volumes: - '${WORLD_DIR:-./data/worlds}:/root/.local/share/Terraria/Worlds' - '${LOG_DIR:-./data/logs}:/tshock/logs' - '${BACKUP_DIR:-./data/backups}:/tshock/backups' - '${PLUGIN_DIR:-./data/plugins}:/plugins' environment: TZ: 'Asia/Tokyo' WORLD_FILENAME: 'MyWorldName.wld' ワールドの新規作成 autocreateオプションにはワールドサイズを数値で指定する（1: Small, 2: Medium, 3: Large）。 ここではSmallを指定している。 環境変数WORLD_FILENAMEが設定されていると実行に失敗するので、-e WORLD_FILENAME=で外しておく。 docker-compose run --rm -e WORLD_FILENAME= terraria -world /root/.local/share/Terraria/Worlds/MyWorldName.wld -autocreate 1 作成完了後、サーバが起動し、サーバコンソールが開く。 バックグラウンド起動にするため、ここでは一旦サーバを停止しておく。 サーバの起動 docker-compose up -d docker-compose logs -f tail -f data/logs/*.log サーバコンソールを開く Dockerコンテナ名を調べる。ここでは、tshock_terraria_1とする。 docker-compose ps 以下コマンドでサーバコンソールが開く。 Ctrl+cするとサーバが停止してしまうので、脱出するときはCtrl+p Ctrl+qを押す。 docker attach tshock_terraria_1 設定・権限の変更 TShockにはバニラと異なる細かいデフォルト設定や権限機能があるので注意。 設定では、デフォルトで初期スポーン地点保護が有効化、墓生成が無効化されている。 権限では、デフォルトでNPCの部屋割り当て、ボス召喚などが無効化されている。 また、TShockのバージョンによってコマンドや設定方法に差異がある。 ...

Docker Hubにアクセストークンを追加する。 https://hub.docker.com/settings/security リポジトリのSettingsから、Secretsを開き、New repository secretから DOCKER_USERNAME、DOCKER_PASSWORDを追加する。 DOCKER_USERNAMEはDocker Hub上のユーザ名、 DOCKER_PASSWORDはアクセストークンを設定する。 以下のファイルをリポジトリに追加する（ファイル名docker.ymlは変更可）。 mainブランチにgit pushされたとき、Dockerイメージのビルドが走り、イメージがDocker Hubにdocker pushされる。 .github/workflows/docker.yml name: Push to Docker registry on: push: branches: - main jobs: push: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Login to Docker Hub uses: actions-hub/docker/login@master env: DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }} DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }} DOCKER_REGISTRY_URL: docker.io - name: Build :latest if: success() run: docker build -t username/imagename:latest . - name: Deploy :latest if: success() uses: actions-hub/docker@master with: args: push username/imagename:latest

2023-05-18 追記：この記事には、改訂版（2023年版）があります。 リポジトリ構造 .gitlab-ci.yml app/ Dockerfile .gitlab-ci.yml stages: - build build: stage: build image: docker:20.10 services: - docker:dind rules: - if: $CI_COMMIT_BRANCH == "main" script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker build ./app -t $CI_REGISTRY_IMAGE:latest - docker push $CI_REGISTRY_IMAGE:latest

以前にもOpen JTalkを触っていたが、時間が経った＆記事が雑だったのでDockerでまとめ直しておく。 Open JTalk - aoirint’s note Dockerfileを作る。 FROM ubuntu:bionic RUN apt-get update && \ apt-get install -y \ open-jtalk \ open-jtalk-mecab-naist-jdic \ hts-voice-nitech-jp-atr503-m001 WORKDIR /data ENTRYPOINT [ "open_jtalk" ] mecab-naist-jdicは形態素解析辞書。 hts-voiceはボイスファイルだが、別途htsvoiceを用意する場合は不要。 ビルドする。 docker build . -t aoirint/open_jtalk 実行する。 echo "こんにちは" > text.txt # テキストファイルの文字列から音声を生成 docker run --rm -v "$PWD:/data" aoirint/open_jtalk -x /var/lib/mecab/dic/open-jtalk/naist-jdic/ -m /usr/share/hts-voice/nitech-jp-atr503-m001/nitech_jp_atr503_m001.htsvoice text.txt -ow output.wav # 標準入力の文字列から音声を生成 cat text.txt | docker run --rm -i -v "$PWD:/data" aoirint/open_jtalk -x /var/lib/mecab/dic/open-jtalk/naist-jdic/ -m /usr/share/hts-voice/nitech-jp-atr503-m001/nitech_jp_atr503_m001.htsvoice -ow output.wav # 標準入力の文字列から音声を生成して、標準出力に書き出す（wav形式） cat text.txt | docker run --rm -i -v "$PWD:/data" aoirint/open_jtalk -x /var/lib/mecab/dic/open-jtalk/naist-jdic/ -m /usr/share/hts-voice/nitech-jp-atr503-m001/nitech_jp_atr503_m001.htsvoice -ow /dev/stdout > output.wav ffmpegで出力されたwavファイルを見るとこのような形式。 ...

SSHポートフォワーディング：踏み台による中継接続 SSHポートフォワーディングには、 ローカルポートフォワーディング、 リモートポートフォワーディングの2種類があります。 sshポートフォワーディング - Qiita ローカルポートフォワーディングでは、 SSHサーバ側から見えるネットワークポートを SSHクライアント側に転送することができます。 例えば、ファイアウォール（NAT）に守られたネットワーク（ネットワークA）内にあるWebサーバ（ホストX）に 外部ネットワーク（ネットワークB）にあるクライアント（ホストY）から接続したいとき、 踏み台となる、ネットワークBから接続可能なSSHサーバ（ホストZ）がネットワークA内にあれば、 ホストYがホストZにSSH接続することで、 ホストXのWebサーバのネットワークポートに、 ホストYの指定したポートから接続できるようになります （「ホスト」は「各ネットワークに接続した、NICに割り当てられたIPアドレス」に対応）。 [email protected]: $ ssh [email protected] -L "127.0.0.1:10080:hostX.networkA.example:80" [email protected]: $ wget http://127.0.0.1:10080/index.html I am "hostX.networkA.example:80". リモートポートフォワーディングでは、 SSHクライアント側から見えるネットワークポートを SSHサーバ側に転送することができます。 先の例でいうと、ホストXがネットワークBに接続していて、 ファイアウォール（NAT）によってネットワークAにあるホストZから接続できないとき、 ホストYがホストZにSSH接続することで、ホストZからホストXに接続できるようになります。 [email protected]: $ ssh [email protected] -R "127.0.0.1:10080:hostX.networkB.example:80" [email protected]: $ wget http://127.0.0.1:10080/index.html I am "hostX.networkB.example:80". この方法は、ネットワーク内のあるホストにSSH接続ができる環境さえあれば、 VPNや他のTCPプロキシをセットアップするより簡単に隠されたネットワークにアクセスすることができるように思います。 ポートプロキシサーバ：2種類のSSHポートフォワーディングの組み合わせ ここで、別の構成のネットワークについても考えてみます。 新しくネットワークCを導入して、 ホストXはNAT内のネットワークC（hostX.networkC.example）、 ホストYはNAT内のネットワークB（hostY.networkB.example）、 ホストZはネットワークB、Cからともに接続可能なネットワークA（hostZ.networkA.example） という構成を考えてみます。 この構成で、ホストYからホストXに接続可能な環境を作るには、次のような手順が考えられます。 ホストXからホストZにSSH接続し、リモートポートフォワーディングによってホストZ上の"ポートQ"をホストX上の"ポートP"に転送する ホストYからホストZにSSH接続し、ローカルポートフォワーディングによってホストY上の"ポートR"をホストZ上の"ポートQ"に転送する これにより、ホストYは、自身のポートRを使って、ホストXのポートPに接続することができます。 もしホストXに物理的にアクセスできない環境でも、 あらかじめホストXをホストZに常時接続するように設定しておけば、 その接続（ポートQからポートPへの転送）が生きている限り、好きなタイミングでホストYからホストXに接続（ポートRからポートQへの転送、すなわちポートRからポートPへの転送）することができます。 SSH Port Forwardingを使ったPort Proxy Server in Docker 前項のポートプロキシサーバの問題として、次の3つを考えました。 ...

$ docker -v Docker version 20.10.0, build 7287ab3 $ brew -v Homebrew 2.6.2 Homebrew/homebrew-core (git revision ce927; last commit 2020-12-19) Homebrew/homebrew-cask (git revision eb977; last commit 2020-12-19) $ brew info xquartz xquartz: 2.7.11 (auto_updates) https://www.xquartz.org/ /usr/local/Caskroom/xquartz/2.7.11 (74.6MB) From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/xquartz.rb ==> Name XQuartz ==> Description Open-source version of the X.Org X Window System Docker Desktop for Mac 3.0.2 (50996) macOS Catalina Version 10.15.7 XQuartzのインストール（HomebrewとHomebrew Cask） 現在はbrew caskコマンドは非推奨で、brewだけでOK（あるいは--caskオプションをつける）。 XQuartzの場合は--caskをつけなくても内部で勝手にbrew caskとしてインストールしてくれた。 Homebrew CaskというのはGUIアプリケーション向けのHomebrewの拡張らしいが、Homebrewと何が違うのかわからん。 Warning: Calling brew cask install is deprecated! Use brew install [--cask] instead. The Missing Package Manager for macOS (or Linux) — Homebrew homebrew-cask — Homebrew Formulae Homebrew/homebrew-cask: 🍻 A CLI workflow for the administration of macOS applications distributed as binaries command line - What is the difference between brew and brew cask? - Ask Different homebrew-cask/USAGE.md at master · Homebrew/homebrew-cask Homebrewは、開発元からソースコードが配布されていて、そのコンパイル済みのバイナリ（またはソースダウンロード＋自動ローカルビルド）を提供するもので、 Homebrew Caskは、*.dmgが配布されていてマウントして*.appを/Applicationsにコピーする操作（実際には/usr/local/Caskroomにインストールする）のを自動化する、というものなのだろうか? --caskを明示するのは両方に登録されていてもCaskを優先するみたいな指定なのか? XQuartzの場合は--caskを付けなくてもCaskとしてインストールされた。 ...