はじめに ファイルサーバを建てるにあたって、割と簡単に実現できそうで、かなり便利そうなNextcloudを採用することにしました。 ただし、手動インストール作業で手間取ったり、次回建てるときに手順書通りに進まなかったりするのが嫌なので、Docker環境にこだわりました。 ネット上に確認できる情報では不満・不十分な部分があったので、自分なりに改良しています。 なお、試しに使ってみたかっただけなので、最低限の設定にしてあります。 手順 Docker環境でNextcloudを建てる GUIで各種設定をする ポート開放をする クライアントソフトを導入する。 1. Docker環境でNextcloudを建てる 以下の2ファイルを同一ディレクトリに用意します。 docker-compose version: "3" services: db: image: mariadb:10.5 restart: unless-stopped command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW volumes: - type: volume source: db target: /var/lib/mysql env_file: - ./db.env app: image: nextcloud:22.2.0-apache restart: unless-stopped ports: - 8080:80 volumes: - type: volume source: app target: /var/www/html environment: - MYSQL_HOST=db env_file: - ./db.env depends_on: - db volumes: db: name: nextcloud_db app: name: nextcloud_app ボリューム名指定が重要です。 未指定だと、親ディレクトリ名が含まれたボリュームが作成されます。 そのため、親ディレクトリ名を変えるだけで過去のデータが引き継げなくなってしまうため、指定しておくとよいでしょう。 また、個人的にはバインドマウントを利用したかったのですが、少なくともWindows環境においてレスポンスが著しく悪化したためボリュームマウントとしました。 db.env MYSQL_ROOT_PASSWORD=password MYSQL_USER=nextcloud MYSQL_PASSWORD=password MYSQL_DATABASE=nextcloud PHP_UPLOAD_LIMIT=2048M NEXTCLOUD_TRUSTED_DOMAINS=「ポート開放する場合はサーバアドレスを入力」 デフォルトでは、1ファイルあたりの最大アップロードサイズが512MBです。 PHP_UPLOAD_LIMIT を指定することで、これを2048MBまで拡張します。 作成されたコンテナの /usr/local/etc/php/conf.d/nextcloud.ini を見てみると、 PHP_UPLOAD_LIMIT という環境変数を参照していたことが確認できたため、このようにしました。 公式ドキュメントや他サイトで確認したわけではないので、他にいい方法があるのかもしれませんが、これで正常に動作はしています。 2. GUIで各種設定をする。 しばらく待つと、 http://localhost:8080 にて次のような画面が表示されます。 適当なユーザ名とパスワードで管理者アカウントを作成します。 あとはユーザアカウントを作成するなど、その他自由に設定していきます。 3. ポート開放をする 最も厄介だった作業です。 我が家は集合住宅向けのプロバイダ契約であって、グローバルなIPv4アドレスが割り当てられていませんでした。 また、我が家の契約ではIPv6 over IPv4でVPNが利用できないようで、VPNも断念しました。 仕方がないので、IPv6のポート開放で妥協しました。 幸いにも、自分の周りのネットワークはすべてIPv6に対応しているので、問題なくファイル共有できそうですが、しかし気軽に他人とリンクによるファイル共有などはしにくい欠点は残ります。 ポート開放手順はおま環なので省略します。 ネットワークの知識が全く無くて困っているのなら、設定するのが難しい上に危ない自体になりかねないので、一旦ローカルで遊ぶに留めるのが吉だろうと思います。 4. クライアントソフトを導入する NextcloudにはPCやモバイル向けのクライアントソフトウェアがあり、これらを導入することで、OneDriveなどのクラウドストレージなどと変わらない利便性を享受できます。 さいごに サーバ・ネットワーク周りに関してはズブの素人でしたが、今回の作業を通していろいろと勉強になりました。 直近の目標は、RAIDを組んで冗長化するなど、ファイルサーバとしての信頼性を高めていきたいと思います。 参考文献 「Nextcloud Docker-Compose」などと検索して出てくる記事たくさん

はじめに Dockerを使うのに、普段はメインPC(Windows10 -> 11に最近アップしました)に入れているのですが、タイトルにある通り、Windows Server 2016に入れようとふと思い立ちました。 いきなりつまづいた ということでPowerShellから以下のコマンドを実行しました Install-Module DockerMsftProvider -Force ところが、いきなりエラー 画面のキャプチャーしてなかったので、細かいところは忘れてしまいましたが、とにかく「インターネット接続を確認しろ」というような感じのメッセージでした。 「いや、ネットつながってるし・・・」と思いながら、いろいろと調べてみると、どうやら通信がうまくいっていないらしい。 とりあえず解決した方法 きちんと理解しているわけではないので、同じようにつまづいた方の参考になればと思うのと、自分の備忘録として記録しておきます。 PowerShellで最初に以下を実行 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 要するに、通信で使用するSSLのバージョンを1.2にしましょうということですが、これでうまくいきました。

はじめに Dockerfileやdocker-compose.yml、その他のファイルのコードを修正した際、どのようにコンテナを起動すればよいか分からなかったため、まとめてみました。 Dockerのイメージとコンテナの違い イメージ: 実行環境の構成を保存した情報 コンテナ: image を実際に動かした実行環境 以下のポイントも抑える必要があります。 ・コンテナ を動かすには、ベースとなる イメージ が必ず必要なこと ・コンテナ を破棄しても イメージ が残っている場合があること ・リポジトリ内のソースコードは、 イメージ 内に含まれている場合と コンテナ 上に含まれている場合があること Docker起動までの流れ イメージ構築→コンテナ構築→コンテナ起動 コマンド イメージ構築 コンテナ構築 コンテナ起動 build ○ × × up △(--build必要) ○ ○ start × × ○ run ○ （単独） ○ （単独） ○ （単独） イメージ構築→コンテナ構築→コンテナ起動 # フォアグラウンドで起動 docker-compose up --build # バックグラウンドで起動 docker-compose up --build -d イメージ構築のみ docker-compose build -d Dockerfile更新の反映する場合 イメージ構築→コンテナ構築→コンテナ起動が必要 Dockerは一度ビルドするとキャッシュというのが作成され、2回め移行のビルド処理がはやくなります。 ただし、Dockerfileを更新する場合、--no-cache オプションを付けないと、Dockerはキャッシュを使ってimageを構築してしまうので、更新したDockerfileを見てくれず新しいimageが作られません。 # イメージ再構築 docker-compose build --no-cache # コンテナ構築・起動（バックグラウンド） docker-compose up -d Dockerfile更新時は、イメージから作り直す必要があります。 docker-compose.yml更新の反映する場合 docker-compose.yml の記載内容のうち build sectionを編集した場合 イメージ構築→コンテナ構築→コンテナ起動が必要 # イメージ再構築 docker-compose build # コンテナ構築・起動（バックグラウンド） docker-compose up -d docker-compose.yml の記載内容のうち build section以外を編集した場合 コンテナ構築→コンテナ起動が必要 docker-compose up -d Dockerfileとdocker-compose.yml以外のファイル更新を反映する場合 Dockerfile 内で ADD や COPY によって、反映したいファイルがイメージに取り込まれている場合 Dockerfileの中でローカルのソースコードを読み込む処理がある場合は、イメージの再構築が必要です。 （イメージ内でソースコードを抱えているため、ローカル側のソースコードの修正が反映しないので、作り直す必要がある） イメージ構築→コンテナ構築→コンテナ起動が必要 # イメージ再構築 docker-compose build --no-cache # コンテナ構築・起動（バックグラウンド） docker-compose up -d 反映したいファイルがイメージに取り込まれていない場合 即反映される場合と、コンテナ構築→コンテナ起動が必要なパターンがあります # コンテナ構築・起動（バックグラウンド） docker-compose up --build -d ローカルのボリュームとコンテナのボリュームをマウントしてる場合は、即反映されるため、特にすることはありません。 単独のサービスのイメージ構築→コンテナ構築→コンテナ起動 docker-compose run サービス名 # コンテナを起動後、指定したコマンドを実行する docker-compose run コンテナ名 rails new 起動中のコンテナ内でコマンド実行 #　起動中のコンテナのシェルへ接続 docker exec -it コンテナ名 /bin/bash [root@xxxxxxx /]# ログ確認 # 最新5行からtailする docker-compose logs -f --tail="5" # 最新5行からタイムスタンプ付きでtailする docker-compose logs -f --tail="5" -t コンテナの開始と停止 # 開始 docker-compose start # 再起動 docker-compose restart # 停止 docker-compose stop 後片付け # 停止と削除（コンテナ・ネットワーク） docker-compose down # 停止と削除（コンテナ・ネットワーク・イメージ） docker-compose down --rmi all # 停止と削除（コンテナ・ネットワーク・ボリューム） docker-compose down -v # 全てを無に返す docker-compose down --rmi all --volumes イメージの一覧を確認 docker images # REPOSITORY TAG IMAGE ID CREATED SIZE コンテナの一覧を確認 docker ps -a # CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 参考記事 ・docker-compose up とか build とか start とかの違いを理解できていなかったのでまとめてみた ・Docker利用時のソースコードの変更反映

GitlabのCIが動かない！ バイト先でdockerを使ってrailsアプリケーションを管理していましたが， 自動テストをするために以下のサイトを参照してGitlab-CIの設定をしました． https://www.insight-tec.com/tech-blog/20201222_gitlab_runner/ 一通りの設定をして動いたので喜んでいたのもつかの間 気が付いたらこんなエラーが発生していた． Reinitialized existing Git repository in /home/gitlab-runner/builds/*****/0/*****/*****/.git Checking out 0cff3126 as master... warning: failed to remove tmp/***: 許可がありません ざっくりまとめると， テストをするためにローカルにデプロイしたいから不要なファイルを削除しようとしたら 許可が無くて削除できないよ！ って感じでした． なぜこのようなことが起きたか 調査の過程などを省いて結論に飛びますが， docker-composeを動かす上で，コンテナ内で処理をする際にroot権限で処理されるように設定していました． その結果，dockerコンテナ内で作成されたファイルやフォルダには管理者権限が付与されるようになっていました． そのため1回目のテストでは問題なく動きますが，2回目以降では1回目でコンテナ内で作成されたファイルが， 権限の問題で操作ができなくなってしまったと考えています． 解決方法 権限の問題なので方法に関してはいくらでもあると思います． やり方としては、 CIの最後に特定のファイルを削除する処理を追加 CIをrootユーザーで実行,または管理者権限のあるユーザーで実行 テスト毎に権限の書き換えを事項 今回は３つ目の方法を行いました． 具体的な方法としては gitlab-runnerにCIを登録する際に，--pre-clone-scriptを追加する方法です． sudo gitlab-runner register -n --executor shell --tag-list "blog-sandbox" --url https://gitlab.com/ --registration-token $GITLAB_SPECIFIC_RUNNER_TOKEN --description "shell executor for sandbox" --pre-clone-script "sudo chown -R gitlab-runner:gitlab-runner ." これによってクローンの前に権限の書き換えを行うようになります． またこのままだと管理者の書き換えの際にパスワードを求められたりするので，ユーザーの権限を変更します． 以下のコマンドで/etc/sudoersを開きます． sudo visudo そして最後の行に以下の一文を書き加えます． gitlab-runner ALL=(ALL) NOPASSWD:ALL これによりgilab-runnerのユーザーがsudoを実行してもパスワードを求められることがなくなり， CIが動くようになりました．

windowsでの分析環境構築にあたって、Dockerの中にanacondaをインストールして更にその中でanacondaの仮想環境を設定して分析環境とします。 1. docker のインストール 以下のリンクからDocker Desktop for windowsをダウンロードします。 なお、実行時のトラブルシューティングは以下; 2. docker にanacondaイメージをインストール power shellで以下を実行します。（以下すべてpower shell内） docker pull continuumio/anaconda3 3. docker にコンテナを生成 インストールしたanacondaイメージからコンテナを生成します。 docker run --name CONTAINER_NAME -it -p 8888:8888 -v "$(pwd):/home" continuumio/anaconda3 /bin/bash なお、ctrl+d などで一度ストップしたコンテナのインタラクティブでの再開は以下。 docker start CONTAINER_NAME -i 4. 仮想環境の設定 コンテナ内でバージョンの異なるpython等を利用したいときのために、仮想環境を設定します。 conda create -n ENV_NAME python==X.X conda activate ENV_NAME 5. Jupyter notebookの立ち上げ jupyter notebookを立ち上げます。 jupyter notebook --port 8888 --ip=0.0.0.0 --allow-root

DockerHubが無課金で自動ビルド出来なくなった 公式ブログの記事によるとDockerHubの自動ビルドが暗号通貨マイニングに悪用されているため、2021年6月18日から無料利用枠でのAutobuildを廃止したとのこと。 CircleCIでDockerイメージビルドしてDockerHubにプッシュする DockerHubには課金せず、CircleCIでDockerイメージをビルドしてDockerHubにプッシュする方法を考える。 CircleCIで使用する自前executorが必要なので、本末転倒だがCirleCIでビルドしてDockerHubに置くことにする。 手順は以下の通り GitHubにレポジトリを作って.circleci/config.ymlとDockerfileを置く DockerHubにレポジトリを用意 CirleCIに環境変数と登録しビルド〜プッシュを実行 .circleci/config.ymlの構成 GitHubのレポジトリにアップしたconfig.ymlはこちら。 再利用性を高めるため以下の3つのブロックで構成している。 commands commandsは5つ用意した。 command-docker_checksumはコンテキストディレクトリからキャッシュ用のチェックサムを生成する command-docker_buildはビルドを実行する command-docker_loadはキャッシュをロードする command-docker_saveはキャッシュを保存する command-docker_pushはプッシュを実行する commands commands: command-docker_checksum: parameters: context: type: string steps: - run: name: generate checksum.txt command: | rm -f /tmp/checksum.txt cat $(find << parameters.context >> -type f | sort) >> /tmp/checksum.txt command-docker_build: parameters: context: type: string dockerfile: type: string default: Dockerfile target: type: string default: "" image: type: string tag: type: string default: build steps: - run: name: docker login command: | docker login -u $DOCKER_LOGIN -p $DOCKER_PASSWORD - run: name: docker build command: | if [ -z "<< parameters.target >>" ]; then docker build --tag=<< parameters.image >>:<< parameters.tag >> --file=<< parameters.context >>/<< parameters.dockerfile >> << parameters.context >> else docker build --tag=<< parameters.image >>:<< parameters.tag >> --file=<< parameters.context >>/<< parameters.dockerfile >> --target << parameters.target >> << parameters.context >> fi command-docker_load: parameters: workdir: type: string default: /tmp/docker image: type: string tag: type: string default: build steps: - run: name: docker load command: | if [ -f "<< parameters.workdir >>/$(basename '<< parameters.image >>')_<< parameters.tag >>.tgz" ]; then gunzip -c << parameters.workdir >>/$(basename '<< parameters.image >>')_<< parameters.tag >>.tgz | docker load docker images << parameters.image >>:<< parameters.tag >> else echo "no cache" fi command-docker_save: parameters: workdir: type: string default: /tmp/docker image: type: string tag: type: string default: build steps: - run: name: docker save command: | if [ -n "$(docker images -q << parameters.image >>:<< parameters.tag >>)" ]; then mkdir -p << parameters.workdir >> docker save << parameters.image >>:<< parameters.tag >> $(docker history -q << parameters.image >>:<< parameters.tag >> | tail -n +2 | grep -v \<missing\> | tr '\n' ' ') | gzip > << parameters.workdir >>/$(basename '<< parameters.image >>')_<< parameters.tag >>.tgz else exit 1 fi command-docker_push: parameters: image: type: string tag: type: string default: build repo: type: string steps: - run: name: docker login command: | docker login -u $DOCKER_LOGIN -p $DOCKER_PASSWORD - run: name: docker push command: | if [ -n "$(docker images -q << parameters.image >>:<< parameters.tag >>)" ]; then if [ -n "${CIRCLE_TAG}" ]; then docker tag << parameters.image >>:<< parameters.tag >> ${DOCKER_LOGIN}/<< parameters.repo >>:${CIRCLE_TAG} docker images ${DOCKER_LOGIN}/<< parameters.repo >>:${CIRCLE_TAG} docker push ${DOCKER_LOGIN}/<< parameters.repo >>:${CIRCLE_TAG} else docker tag << parameters.image >>:<< parameters.tag >> ${DOCKER_LOGIN}/<< parameters.repo >>:latest docker images ${DOCKER_LOGIN}/<< parameters.repo >>:latest docker push ${DOCKER_LOGIN}/<< parameters.repo >>:latest fi else exit 1 fi executors docker buildとdocker pushを使いたいのでDocker公式イメージをexecutorsとして利用する。 executors executors: docker: docker: - image: library/docker:latest auth: username: $DOCKER_LOGIN password: $DOCKER_PASSWORD jobsとworkflows commandsに渡すcontextとimageはGitHubレポジトリと同じ。キャッシュ名も同様。 jobs jobs: docker_build: executor: name: docker steps: - setup_remote_docker - checkout - command-docker_checksum: context: awscli-executor - restore_cache: keys: - awscli-executor-v1-{{ checksum "/tmp/checksum.txt" }} - awscli-executor-v1 - command-docker_load: image: awscli-executor - command-docker_build: context: awscli-executor image: awscli-executor - command-docker_save: image: awscli-executor - save_cache: key: awscli-executor-v1-{{ checksum "/tmp/checksum.txt" }} paths: - /tmp/docker - persist_to_workspace: root: /tmp paths: - docker docker_push: executor: name: docker steps: - setup_remote_docker - checkout - command-docker_checksum: context: awscli-executor - restore_cache: keys: - awscli-executor-v1-{{ checksum "/tmp/checksum.txt" }} - awscli-executor-v1 - command-docker_load: image: awscli-executor - command-docker_push: image: awscli-executor repo: awscli-executor workflowsはmainブランチはlatestとしてタグはタグ名でDockerHubにDockerイメージがプッシュされる。 workflows workflows: version: 2 default: jobs: - docker_build: filters: tags: only: /.*/ - docker_push: requires: - docker_build filters: tags: only: /.*/ branches: only: main Dockerfile AWS CLIのexecutorのDockerfileをconfig.ymlに書いたcontextと同じ名前のディレクトリに配置する。 Dockerfile FROM library/docker:19.03.15 ENV AWS_CLI_VERSION 2.0.63 ENV GLIBC_VER 2.31-r0 RUN apk update \ && apk add --no-cache \ bash \ 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 --virtual .build-deps \ binutils \ glibc-${GLIBC_VER}.apk \ glibc-bin-${GLIBC_VER}.apk \ unzip \ zip \ && curl -sL https://awscli.amazonaws.com/awscli-exe-linux-x86_64-${AWS_CLI_VERSION}.zip -o awscliv2.zip \ && unzip -q awscliv2.zip \ && ./aws/install \ && rm -f awscliv2.zip \ && apk del .build-deps \ && rm -rf /var/cache/apk/* DockerHubにレポジトリを用意 config.ymlに書いたimage名と同じ名前の空のレポジトリを作成するだけ。 CirleCIの設定 作成したGitHubレポジトリを取り込んでDockerHubログインの情報を環境変数（DOCKER_LOGINとDOCKER_PASSWORD）として登録する。 DockerHubにプッシュしたイメージの確認 これでGitHubへのプッシュすれば今までと同じようにDockerHubにビルドイメージが自動でアップされる。

本シリーズのトップページ https://qiita.com/items/dfb16ffcbbe7745e765e 概要 変則的だが、職場の "非K8s環境" で Prometheus を導入することになったので 調査・導入検討をしてみた. なお、職場の "非K8s環境" ではすでに「Zabbix 4.0」を導入しているが、 将来に備えて Prometheus を使ってみたいらしい. そこで、オンプレ環境で、docker-compose を用いて Prometheus サーバを立てたので、 手順を書き残しておく. また、Zabbix ユーザ視点でのコメントも少し書き添えておく. 　 環境 ホスト(物理PC) DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS" $ hostname -I 192.168.10.47 構築する環境 項目 値 備考 Prometheus version 2.30.3 他者の環境では起動エラーになるといったトラブルを避けたいので、バージョン指定している Grafana 8.2.0-ubuntu 同上 手順 1. ファイル構成 ファイル構成は次の通り. $ tree . --charset=C --dirsfirst . |-- PV | |-- etc | | `-- prometheus | | `-- prometheus.yml ..... 後述 | `-- var | `-- lib | `-- grafana ............ 現時点では空っぽのディレクトリである `-- docker-compose.yml 2. docker-compose.yml を作成する 公式手順にある Dockerfile を基にして、docker-compose.yml を作成する. 9090番は「Cockpit (Linux サーバ管理ツール)」と衝突するらしいので、 ここでは 49090 に変更した.1 また、3000番も Rails などと衝突する恐れがあるので、43003番に変更している. なお、9090番ポートは Zabbix における 10051番ポートに該当する. (サーバ側が LISTEN するポートである) version: '3.7' services: prometheus: image: prom/prometheus:v2.30.3 container_name: myprometheus_v2_30_3 logging: driver: "json-file" options: max-size: "10m" max-file: "7" ports: - 49090:9090 volumes: - ./PV/etc/prometheus/:/etc/prometheus/ grafana: image: grafana/grafana:8.2.0-ubuntu container_name: mygrafana_v8_2_0 ports: - '43003:3000' user: 'root' logging: driver: "json-file" options: max-size: "10m" max-file: "7" volumes: - './PV/var/lib/grafana:/var/lib/grafana' 2. Prometheus 設定ファイルを作成する Zabbix での /etc/zabbix/zabbix_server.conf に該当するファイル. 下記の 物理ホストのIPアドレス 192.168.10.47 は適宜読み替えること. PV/etc/prometheus/prometheus.yml global: # How frequently to scrape targets by default. scrape_interval: 15s # How frequently to evaluate rules. evaluation_interval: 15s # A list of scrape configurations. scrape_configs: - job_name: 'prometheus' static_configs: - targets: ['192.168.10.47:49090'] #?適宜読み替えること. 3. コンテナを稼働させる 3-1. 稼働させる Zabbix とは異なり、別途 Database を導入する必要が無い. また Zabbix で実施している PHP のセットアップも不要である. インストールという面では Prometheus の方が断然楽である. $ docker-compose up -d 3-2. 稼働確認をする CLI での確認 $ docker-compose ps Name Command State Ports --------------------------------------------------------------------------------------- mygrafana_v8_2_0 /run.sh Up 0.0.0.0:43003->3000/tcp myprometheus_v2_30_3 /bin/prometheus --config.f ... Up 0.0.0.0:49090->9090/tcp WEB-UI での確認 ・http://:49090/ にアクセスして Prometheus の UI が表示されていることを確認する. ・http://:43003 にアクセスして Grafana の UI が表示されていることを確認する. 　 　 4. Grafana と Prometheus を連携させる 4-1. Grafana WEB-UI にログインする ここでは http://<IP>:43003 である. 初回ログインID・PW は「admin」「admin」である. 4-2. Prometheus を登録する 4-2-1. 「DATA SOURCES」から Prometheus を選択する 4-2-2. Prometheus を稼働させているマシンの IP と ポートを設定する 画面下部にある「Save & test」を実行して「Datasource updated」が表示されれば良い 5. Grafana Dashboard に監視項目を登録してみる Prometheus サーバに対するリクエスト回数を表示する次のクエリを適用する. 「prometheus_http_requests_total」 表示内容が問題無ければ、保存する. 6. 稼働後のファイル構成 $ tree . --charset=C --dirsfirst . |-- PV | |-- etc | | `-- prometheus | | `-- prometheus.yml | `-- var | `-- lib | `-- grafana | |-- csv [error opening dir] | |-- plugins | |-- png [error opening dir] | `-- grafana.db `-- docker-compose.yml 　 以上. 参考にした情報 ・『[改訂3版] Zabbix統合監視実践入門 (技術評論社)』 ・https://kazuhira-r.hatenablog.com/entry/2019/04/29/025816 ・Prometheus 公式 ・CentOS 8 実践ガイド［サーバ構築編］ ・Kubernetes実践ガイド　クラウドネイティブアプリケーションを支える技術 ・PrometheusでKubernetesを監視する本 (電子版) 　 　 ・CentOS 8 実践ガイド［サーバ構築編］ ↩

環境 MacOS Big Sur 11.6 目的 好きなようにSQLイジイジしたい すること Docker-composeでMySqlコンテナを起動する MySQL Workbenchで接続する MySQL WorkbenchでSQLをexportする MySQL WorkbenchでSQLをimportする Docker-composeでMySQLコンテナを起動する dockerコンテナを立ち上げるまでこれ通りに行う https://blog.hiros-dot.net/?p=10469 docker |---mysql |---data |---sql % mkdir docker % mkdir docker/mysql % mkdir docker/mysql/data % mkdir docker/mysql/sql mysql/my.cnfを作成 [mysqld] character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci [client] default-character-set=utf8mb4 ルートにdocker-compose.ymlを作成 version: '3' services: mysqldb: image: mysql:5.7 container_name: mysql_container environment: MYSQL_ROOT_PASSWORD: root MYSQL_DATABASE: my_testdb MYSQL_USER: docker MYSQL_PASSWORD: docker TZ: 'Asia/Tokyo' volumes: - ./docker/db/data:/var/lib/mysql - ./docker/db/my.cnf:/etc/mysql/conf.d/my.cnf - ./docker/db/sql:/docker-entrypoint-initdb.d ports: - "3306:3306" command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci Docker起動 ルートでコンテナ立ち上げ % docker-compose up -d コンテナ確認 % docker ps % docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES d9fb41109241 mysql:5.7 "docker-entrypoint.s…" 26 minutes ago Up 26 minutes 0.0.0.0:3306->3306/tcp, 33060/tcp mysql_container MySQL Workbenchで接続する こちらのサイトからダウンロードする https://www.mysql.com/products/workbench/ 以下の画像のように設定する 右下の Test Connectionで接続を確認する パスワードは docker-compose.ymlで設定した MYSQL_ROOT_PASSWORD: root 接続が成功すると以下の画像が表示される MySQL WorkbenchでSQLをexportする Server→Data Exportでdumpする ExportするSchemaを選択する Start Exportでファイルが保存される MySQL WorkbenchでSQLをimportする 右クリックで Create Shemaを選択する Shema名を入力して、右下のApplyを押しShemaを作成する Server→Data Importで先程のdumpフォルダを選択する 以上、SQLでいじいじできるようになりました。

事象 タイトル通り。 Dockerfile VOLUME /foo/bar もしくは docker-compose.yml volumes: - /foo/bar といった記述がある場合、 docker commit <ID> <Tag> で起動中コンテナをイメージ化しても、マウントされているディレクトリはイメージに含まれない。 コンテナ内でマウントされているボリュームに含まれるデータは、コミット作業に含まれません。 https://docs.docker.jp/engine/reference/commandline/commit.html 対策 ファイルを書き換えて VOLUME させないようにするほかなさそう。 Dockerfile 記載の VOLUME を docker-compose.yml 側で無効化するのはできない模様? https://ja.stackoverflow.com/questions/40033/docker-compose%E3%81%A7dockerfile%E3%81%AEvolume%E8%A8%AD%E5%AE%9A%E3%82%92%E8%A7%A3%E9%99%A4%E3%81%99%E3%82%8B%E3%81%93%E3%81%A8%E3%81%AF%E5%8F%AF%E8%83%BD%E3%81%A7%E3%81%97%E3%82%87%E3%81%86%E3%81%8B

1. 概要 UTASとはUTokyo Academic affair System、すなわち東大の学務システムです。 履修登録などができるごく一般的なWebサイトで、成績も表示されます。 ...が、なぜかGPAが計算されません。 GPAとか平均成績順位率の欄はちゃんと用意されているのに、そこは永遠に0のまま。これはバグなのでは。それとも他の学部の人だと正しく表示されてたりするのか...? ということで、DIYの精神を発揮してGPA計算機を作りました。ちなみに初投稿です。 2. 使用した技術 Python : 書きやすい。 Selenium : Webブラウザの操作を自動で行ってくれるフレームワーク。UTASは当然APIなど提供していないのでクリックを多用して愚直にいじります。 docker : 上記二つをローカル環境に依存せずに走らせたいのでコンテナを作ることにします。 3. 成果物 結論から言うとできたものがこれで、使うための情報は多分readmeに揃っています。 ローカル環境に必要なのはdockerとdocker-composeだけで、操作用のブラウザとPython実行環境はコンテナ内に置かれます。 現在の仕様としては、まず前期課程・後期課程などに関わらず全ての単位をひっくるめて計算します。 設定ファイルで以下を変更できます。 各成績の点数重みづけ デフォルトで(優上:4.3, 優:4.0, 良:3.0, 可:2.0, 不可:0.0) 「科目GP」欄にチェックが入っている科目を計算に含めるかどうか 4. 構成・実装 ディレクトリ構成 gcu/ ├app/ │ ├Dockerfile │ ├gcu.py │ ├requirements.txt │ └settings.txt ├docker-compose.yml └readme.md docker-compose.yml docker-composeを用いて2つのコンテナを立てます。 seleniumコンテナ SeleniumHQ/docker-seleniumイメージからコンテナを立てます。ポートは4444、ブラウザはFirefox。 appコンテナ ./appをマウントしつつ、Dockerfileを読み込んでPython実行環境を作ります。 version: "3" services: selenium: image: selenium/standalone-firefox-debug:3.141.59 ports: - 4444:4444 app: build: ./app volumes: - ./app:/app environment: SELENIUM_URL: http://selenium:4444/wd/hub tty: true volumes: - /dev/shm:/dev/shm Dockerfile FROM python:3.6 ENV PYTHONIOENCODING utf-8 WORKDIR /app COPY . . RUN pip install -r requirements.txt requirements.txt ###### Requirements without Version Specifiers ###### selenium ###### Requirements with Version Specifiers ###### settings.txt GPA計算用の設定を記述します。 # This is the setting file of GCU. Don't edit except for the values of the parameters. 4.3 # point of "優上" 4.0 # point of "優" 3.0 # point of "良" 2.0 # point of "可" 0.0 # point of "不可" 1 # 1 if you include courses whose "科目GP" is "*". If you don't want to include, set 0. gcu.py main部のみ抜粋。 from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.support.ui import WebDriverWait if __name__ == "__main__": print("--- GPA Calculator for UTAS (GCU) v1.0 powered by Python & selenium ---") if len(sys.argv) > 1: print_desc() sys.exit(0) student_id = input("student ID: ") student_pass = getpass.getpass("password: ") # set options to start Firefox options = webdriver.FirefoxOptions() options.headless = True # open the new window of the browser print("connecting to the remote browser...") driver = webdriver.Remote( command_executor=os.environ["SELENIUM_URL"], desired_capabilities=options.to_capabilities(), options=options ) try: calc(driver,student_id,student_pass) except Exception as e: print(e) finally: driver.quit() 出力例 --- GPA Calculator for UTAS (GCU) v1.0 powered by Python & selenium --- student ID: HogeHoge password: connecting to the remote browser... Reading setting.txt ... Successfully read setting.txt. Successfully accessed to UTAS and got score tables. Courses taken into account | credits | score ダミー工学 2.0 4.0 ダミー入門 2.0 3.0 ダミー実験 1.0 2.0 --- Result --------------------- Number of credits: 5.00 Sum of scores : 16.00 GPA : 3.20 -------------------------------- 5. 参考資料 Seleniumをすぐに使えるようになるチュートリアル。 dockerの構成を参考にさせていただきました。 6. 困ったこと Seleniumは割と繊細らしく、途中でいくらかハマったので記録を残しておきます。 Chromeだとiframe内の要素のクリックに失敗しやすい input is not clickable なるエラーが出る。 解決できなかったので最終的にFirefoxに切り替えた。その後は安定した。 画面が切り替わった直後はcheckboxのクリックなどが認識されない body要素を一度クリックするなどして画面にフォーカスを当てる必要がある。 よく分からないけどなぜかエラーが出る ページ読み込みなどを待つ時間を設けると解決する場合が意外に多い。 明示的な待機(WebDriverWait)、暗黙的な待機(implicitly_wait)、Pythonによる強制スリープ(time.sleep)の3つを活用する。 ローカル環境にできるだけ依存しないように作ったとはいえ、それでもdockerが必要なので一般の使用にはハードルが高いのは反省点です。 最も手軽に利用可能な形はブラウザ拡張機能だと思われます。 それをしなかったのはひとえに拡張機能の開発経験が無かったからなので、気が向けばそちらも調べたいところ。