- 投稿日：2021-08-29T22:29:25+09:00
docker nodejs を利用時にnode_modulesが作成されなくなった
Description gatsbyやangularでdockerを利用する際に、OSによりinstall内容が変わるmoduleがあり、手元のnode_modulesをそのままdocker環境で利用した場合にErrorを吐く場合があった。 dockerとlocalの環境で別にinstallしようと思い、docker-ignoreに追加 + docker内部でインストールを実施した際にエラーがでたため対処方法を追記。 Refs 関係ありそうだけどさっとしか見なかった。ごめんなさい。 yarnpkg/yarn#5500 yarnpkg/yarn#2240 TL;DR volumesにnode_modulesに追記する。 docker-compose.yml services: app: volumes: - type: volume source: dependencies target: /${WORK_DIRECTORY}/node_modules command: yarn dev volumes: dependencies: 対処方法 node_modulesをvolumeデータとして扱う databaseのデータと同じく、volumeにnode_moduluesを追加する。 雑に使ったdockerfile docker/server.dockerfile FROM node:16-alpine3.11 WORKDIR /app COPY package*.json ./ COPY yarn.lock ./ RUN rm -rf node_modules RUN yarn install --frozen-lockfile 簡易的に作ったdocker-compose.yml docker-compose.yml version: "3.9" services: app: container_name: app build: context: . dockerfile: ./docker/server.dockerfile tty: true restart: always ports: - "3000:3000" volumes: - type: bind source: . target: /app - type: volume # volumeをtypeで指定 source: dependencies # volumeに記載した名前と同じもの target: /app/node_modules # 利用しようとしている場所をtargetに記載 command: yarn dev volumes: db-data: dependencies: # volumeに登録する 気付いた点 dockerfileをXXX.dockerfileにするとVSCのファイルにiconがつく volumeで利用したため、複数のcontainerで使い回せる nocopyを使うとcontainerで相互更新しなくても利用できる cli系統のpackageを別のcontainerで区分けでき、 app: &node_containerで使い回しができる
- 投稿日：2021-08-29T22:15:09+09:00
【Docker】nginx + https-portalを使ってWebサイトをHTTPSでデプロイする話
おはこんにちばんは。 ハイパーエンジニアの@FL1NEです。 HTTPSでWebサイトを展開するのって何気にめんどくさいですよね。 Webサーバーは構築しないといけないし、Let's Encryptとかで証明書も取得しないといけないし。。。 今回はそう言った悩みをDockerのnginxコンテナとhttps-portalコンテナを使って解決していきます。 何 HTTPSでサーバーをデプロイするのがめんどくさいのでそれをDockerで楽にする話 なお、https-portalはnginxがベースとなっており、リバースプロキシとしても使えるので複数サイトをサブドメインで同一サーバーにホストする際もオススメ (ちなみにDockerのオーバーヘッドとかよりもデプロイの楽さをとっているので、そちらが気になる人は自前でネイティブ実装してどうぞ) 必要なもの サーバー (Dockerが動けばなんでもいいっす) ドメイン (httpsの証明書取得とかで必要なので) Docker + Docker-compose ポート開放とかの基礎知識 リポジトリ 下準備 テストページを用意する 今回の解説では単純なhtmlファイルをデプロイすることにするので、html/index.htmlを作成しておきます。 <!DOCTYPE html> <html> <head> <title>テストページ</title> <meta http-equiv="content-type" charset="UTF-8"> <style> html { color-scheme: light dark; } body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>テストページ</h1> <p>ただのテストページっす</p> </body> </html> nginxのDockerコンテナを作成する (Webサーバー) 下準備も終わったのでまずはテストページを含んだDockerコンテナを作ります。 (Dockerfileを作っておいてビルドできるようにします) FROM nginx:alpine WORKDIR /usr/share/nginx/html COPY ./html /usr/share/nginx/html 試しにビルドして実行してみます docker build -t nginx-website:latest . docker run -d -p 8888:80 nginx-website http://localhost:8888にアクセスして以下のようなページが表示されてればOKです。 これでひとまずWebサーバーのコンテナは作成できました。 https-portalでHTTPS化する https-portalの設定と先ほど作成した version: '3' services: https-portal: image: steveltn/https-portal:latest container_name: https-portal ports: - 80:80 - 443:443 links: - nginx-website restart: always environment: DOMAINS: '[ドメイン名] -> http://nginx-website' STAGE: 'production' #テスト時はコメントアウト推奨 nginx-website: image: nginx-website container_name: nginx-website restart: always このように設定を書きます。 [ドメイン名] のところは利用したいドメインに書き換えてください。 (例: example.com や hoge.example.comのようなドメイン名) また、DNSの設定やファイヤーウォールの設定などを正しく設定しておきましょう ポートは以下のものが解放されている必要があります。 80/tcp (httpアクセスを受け、301でhttpsサイトへ飛ばすのに必要) 443/tcp (httpsでアクセスを受けるのに必要) これらの設定ができたら、docker-compose upでコンテナ群を起動します。 docker-compose up -d 設定したドメイン名にWebブラウザからアクセスし、httpsで接続できていれば完了です。 (初回は証明書発行の時間などがあるので少し起動に時間がかかります) 終わりに 以上の手順で開発したWebサイトなどを楽にhttps化することができました。 https-portalにhttps化を一任することによっていちいち自前でリバースプロキシを用意したりcertbotの設定とかを行わなくて済むようになり便利だと思います。 今回はwebサイトをnginxのコンテナにしてアクセスを受け付けましたが、Dockerのコンテナや同じネットワークに存在するマシンなどは同じようにhttps-portalを使って楽にhttps化できます。 ぜひ皆さんもWebサイトをhttps対応しましょう! 今回紹介しなかった別の設定手法などは参考資料のQiitaページが非常にわかりやすくていいので読んでみてください。 ではでは。 参考資料 Let's Encrypt でhttps化してくれるコンテナ (https-portal) | Qiita https-portal (GitHub) Let's Encrypt 宣伝等 GUNCY'S (グンシーズ) 株式会社GUNCY'Sでは社内や顧客の要望などを一緒に解決へ導くメンバーを広く募集しています。 興味がある方は是非採用ページをご覧ください！ FRONTL1NE (フロントライン) FRONTL1NEは日本のデモシーンなどをはじめとしたクリエイティブな活動や、ゲーム、プログラミング、音楽、映像など様々な分野に興味を持つな人が集うWebサイト・コミュニティです。 是非WebサイトやDiscordを覗いてみてください! Tokyo Demo Fest (東京デモフェスト) Tokyo Demo Festは日本唯一のデモシーン(メガデモ)イベント = デモパーティです。 デモパーティは、コンピュータを用いたプログラミングとアートに 興味のある人々が日本中、世界中から一堂に会し、 デモ作品のコンペティション(コンポ)やセミナーなどを行います。 また、イベント開催中は集まった様々な人たちとの交流が深められます。 最新の情報はTwitterやWebサイトをご確認ください！
- 投稿日：2021-08-29T21:47:56+09:00
ローカルEthereum開発環境を構築する（プライベートチェーン）
はじめに タイトルの通り、ローカルでEthereum開発環境を構築してみたので、内容をまとめてみたいと思います。 ※筆者は普段の業務でLinuxを全く触らないので、その辺は素人です。 間違いがあれば、お手柔らかに。。。アドバイス頂けると幸いです。 ※執筆時は2021/08ですが、最新の情報を追い切れていない可能性もあります。 新しめの技術は急に利用方法、インターフェースが変わることもあるため、ご注意ください。 最終的な構成 ざっくりとした図ですが、こんな感じ。 Docker上に各種環境を構築して、そこにローカル上のVSCode、ブラウザからアクセスします。 手順 1.Dockerコンテナ上にGanache環境を構築 2.Docker上にTruffle環境を構築 ※執筆中... 3.Docker上にReact開発環境を構築 ※執筆中... 4.最後につなげて動かしてみる ※執筆中... ※各手順の詳細はリンク先で記載しています。 さいごに ひとまず、極々簡単なEthereumを利用しての開発環境は構築出来ました。 今回の記事では記載していませんが、DockerComposeで作成した環境をまとめて共有しやすいようにしたいですね。 また、複数ノードを立てての動作確認など、まだまだ要調査が必要なものがあるので、 これから少しずつ進めていきたいと思います。 ちなみに、今回はGanacheを利用しましたが、Ganache-CLI、Gethも少し触ってみました。 その他2つに比べてGanacheはGUIもあり、TXの確認やStorageの確認なども出来るため開発時には使いやすいなと感じました。 ただ、マイニングを自動でやってくれたり、実際のETHを利用しての運用をするわけではないので、 本格的なサービスを見据えて利用する場合は、この辺りの情報／仕組みも確認・検討していくべきですね。 以上ですー。
- 投稿日：2021-08-29T21:34:11+09:00
Docker上にGanache環境を構築する
はじめに Docker上にGanacheをインストールして、GUIでTXの確認を出来るようにする。 下記手順でひとまずDockerのUbuntu上にGanache環境を構築できますが、ちょっと使いづらいかなという部分があります。（末尾に記載） こちらに関しては筆者のLinuxの知識が浅い面もあり、進展あり次第追記していきたいと思います。 バージョン 執筆時点(2021/08/29)での筆者の環境です。 ・Docker: 20.10.8 ・Ubuntu: 20.04 ・Ganache: 2.5.4 手順 1.Docker上にUbuntuのデスクトップ環境を構築する 2.Ganacheのダウンロード 3.Ganacheの起動 1.Docker上にUbuntuのデスクトップ環境を構築する 下記Qiitaの記事を参考に進めて無事リモートデスクトップ環境の構築と、 ローカルからのアクセスが出来ました。 参考：Dockerに構築したLinuxにリモートデスクトップで接続する ※こうやってまとめてくださっていると、普段触らない技術と相対する時に 本当に助かります。ありがとうございます。 今回は上記参考記事からポートフォワードの指定を追加しています。 Ganacheへアクセスするポート番号がデフォルトで7545のため、 ポートフォーワードで外部からコンテナの7545にアクセスできるように指定します。 docker run -name コンテナ名 -p 13389:3389 -p 7545:7545 -it イメージ名 /bin/bash ※7545以外のポートでアクセスしたい場合は-p 7545:7545部分を適宜変更してください。 2.Ganacheのダウンロード リモートデスクトップ接続 コンテナ作成／起動後、ローカル環境からリモートデスクトップでアクセスします。 上記参考手順に従って、リモートデスクトップへアクセスします。 Ganacheのダウンロード リモートデスクトップで接続したUbuntu上のブラウザより Ganacheのサイトへアクセス。 https://www.trufflesuite.com/ganache DOWNLOADボタンを押下。 SaveFileを選択。 フォルダアイコン押下で、エクスプローラでダウンロード先を表示。 デフォルトでDownloadsフォルダへ格納されるため、.AppImageファイルを任意の作業用フォルダへ移動。 ※私は/root/workフォルダへ移動しました。 3.Ganacheの起動 Ganacheの公式手順だとダウンロード後にダブルクリックで実行できるようなのですが、出来ませんでした。 なので、ターミナルから実行していきます。 .appimageファイルのコピー先まで移動して、 下記コマンドを実行して権限を付与します。 # cd コピー先のフォルダパス # chmod a+x ganache-2.5.4-linux-X86_64.AppImage 権限が付与されたので、下記コマンドを叩いてGanacheを起動させます。 ./ganache-2.5.4-linux-X86_64.AppImage --appimage-extract-and-run 少し待つとウインドウが表示されます！ ちなみにこの画面はGoogle Analyticsの追跡を許可するか否かの選択画面です。（Ganache公式手順にも説明あり） 内容を読んで、任意の設定でCONTINUEを押下しましょう。 ※この追跡は匿名で、アカウントデータ・秘密鍵の共有などが行われることはないそうです。 CONTINUE押下後、上記画面が表示されます。 今回は特に設定もせず、さくっと立ち上げてみましょう。 QUICKSTARTを押下します。 上記画面が表示され、Ganacheの起動は完了です！ QUICKSTARTを選択した場合はデフォルトでランダムな10個のアドレスが生成され、それぞれ100ETH保持した状態で起動します。 この状態でプライベートチェーンのEthereum環境が利用できるようになっています。 ただ、注意点として、 QUICKSTARTで起動した場合、Ganacheを終了すると今までの取引履歴が削除されてしまいます。 アドレスも再びランダムなものが10個生成されるため、終了前と同じ環境を利用することができないため、 長期間の作業、運用はできません。 以前の環境を保持しておくためにはQUICKSTARTではなく、WORKSPACEを作成して進めていく必要がありますが、 それはまたTruffleと連携させる際に記載したいと思います。 おわりに 前述した通り、ひとまずGanacheを動かすところまでは完了。 アプリ実行（ダブルクリック）で躓きましたが、起動してからの操作は比較的簡単そうです。 積み残しとして、以下は今後の課題です。 ・コンテナ起動直後はリモートデスクトップで接続できない コンテナ起動直後はxrdpがうまく起動できていない？せいか、リモートデスクトップにアクセスできません。 現状、コンテナ起動後に一度ターミナルで入り、下記コマンドを実行することで、リモートデスクトップでのアクセスが可能になります。 /etc/init.d/xrdp stop /etc/init.d/xrdp start ただ、毎度ターミナルに入って、、、というのは面倒くさい。 コンテナ起動時に任意のスクリプトを実行できるはずなので、要調査。 ・リモートデスクトップアクセス時pidエラーのダイアログが表示される 色々調べてみたところWSL環境ではDockerのコンテナにログインしたユーザーへのpidの紐づけ？が うまくできないようです。 筆者はそもそもpidって？くらいの知識なので、この辺りは要勉強です。汗 ※genieなるものをインストールすればpid=1も利用できるようになるという記事も観ましたが、 うまくいきませんでした。 genie -sを実行すると下記エラーが発生してしまった。 genie: initializing bottle failed; bind mounting hostname ・Ganacheをアイコンダブルクリックで実行できない 本来.AppImageファイルはダブルクリックで実行可能なようですが、 私の環境ではうんともすんとも言いませんでした。 権限周りが怪しいので調べてみたのですが、解決には至りませんでした。 そのため、ひとまず--appimage-extract-and-runオプションを付けて、実行出来るようにしています。 参考 ・LinuxでAppImage形式のアプリを使う方法と注意点のまとめ https://www.virment.com/how-to-use-appimage-linux/ ・第22回 WSL2の新機能を試してみよう https://www.school.ctc-g.co.jp/columns/miyazaki/miyazaki22.html 以上ですー。
- 投稿日：2021-08-29T20:02:59+09:00
Dockerでwordpress構築
はじめに 下記を参考にDockerを使ってWordPressを立ち上げようとしてみたらDB接続確立エラーが発生しました。 その時の対処を備忘録として記載しておきます。 「CentOS7にDockerでWordPressを入れる」 作成環境 Amazon Linux release 2 (Karoo) 作成結果 作業工程 ・Dockerのインストール、Dockerの起動 ・コンテナを作成し、wordpressインストール →DB接続エラーが発生し、中断 ・コンテナ内でvimのインストールとwp-config.phpの編集 →wordpressインストール完了 Dockerのインストール、Docker daemonの起動 ・dockerのインストール yum install docker ・インストール後のバージョン確認 docker -v Docker version 20.10.7, build f0df350 ・Dockerの起動 systemctl start docker ・Dockerの状態確認 systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2021-08-29 04:34:09 UTC; 5h 43min ago Docs: https://docs.docker.com Process: 7585 ExecStartPre=/usr/libexec/docker/docker-setup-runtimes.sh (code=exited, status=0/SUCCESS) 以下略 ・Dockerの実行 上記サイトではエラーが出ていますが出ませんでした。 docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES コンテナを作成し、wordpressインストール コンテナ作成 docker run --name mysql -e MYSQL_ROOT_PASSWORD=mysqlpassword -d mysql:5.7 docker run --name wordpress --link mysql:mysql -d -p 8080:80 wordpress 起動しているコンテナの確認 docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5200b39bef3a wordpress "docker-entrypoint.s…" 32 minutes ago Up 32 minutes 0.0.0.0:8080->80/tcp, :::8080->80/tcp wordpress 3ed4556afe3c mysql:5.7 "docker-entrypoint.s…" 33 minutes ago Up 33 minutes 3306/tcp, 33060/tcp mysql プラウザでを以下URLを叩くとWordPressの画面が表示され、インストール時にDBの接続情報を正しいのを入力しているのにDB接続確立エラーが出てインストールが進まない エラーの対処として以下3点が記載されていた。 「http://VMのIPアドレス:8080」 コンテナ内でvimのインストールとwp-config.phpの編集 エラーの対処としてwp-config.phpにDB接続情報を記載してみたら解決した。 しかしコンテナ内でファイル編集のためにviをするとエラーが発生。 docker exec -it 5200b39bef3a bash vi wp-config.php bash: vi: command not found そこでコンテナ内でvimのインストールの実施 apt-get update apt-get install vim wp-config.phpの編集をして、インストールが進みました vi wp-config.php 以下の箇所に記載 define( 'DB_NAME', 'wpdb' ); /** MySQL database username */ define( 'DB_USER', 'wpadmin' ); /** MySQL database password */ define( 'DB_PASSWORD', 'xxxxxx' );
- 投稿日：2021-08-29T20:02:59+09:00
Dockerでwordpressセットアップ
はじめに 下記を参考にDockerを使ってWordPressを立ち上げようとしてみたらDB接続確立エラーが発生しました。 その時の対処を備忘録として記載しておきます。 「CentOS7にDockerでWordPressを入れる」 作業環境 ・AWS Amazon Linuxサーバ Amazon Linux release 2 (Karoo) ・Docker20.10.7 作業結果 作業工程 ・Dockerのインストール、Dockerの起動 ・コンテナを作成し、wordpressインストール →DB接続エラーが発生し、中断 ・コンテナ内でvimのインストールとwp-config.phpの編集 →wordpressインストール完了 Dockerのインストール、Docker daemonの起動 ・dockerのインストール yum install docker ・インストール後のバージョン確認 docker -v Docker version 20.10.7, build f0df350 ・Dockerの起動 systemctl start docker ・Dockerの状態確認 systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled) Active: active (running) since Sun 2021-08-29 04:34:09 UTC; 5h 43min ago Docs: https://docs.docker.com Process: 7585 ExecStartPre=/usr/libexec/docker/docker-setup-runtimes.sh (code=exited, status=0/SUCCESS) 以下略 ・Dockerの実行 上記サイトではエラーが出ていますが出ませんでした。 docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES コンテナを作成し、wordpressインストール コンテナ作成 docker run --name mysql -e MYSQL_ROOT_PASSWORD=mysqlpassword -d mysql:5.7 docker run --name wordpress --link mysql:mysql -d -p 8080:80 wordpress 起動しているコンテナの確認 docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 5200b39bef3a wordpress "docker-entrypoint.s…" 32 minutes ago Up 32 minutes 0.0.0.0:8080->80/tcp, :::8080->80/tcp wordpress 3ed4556afe3c mysql:5.7 "docker-entrypoint.s…" 33 minutes ago Up 33 minutes 3306/tcp, 33060/tcp mysql プラウザでを以下URLを叩くとWordPressの画面が表示され、セットアップ時にDBの接続情報を正しいのを入力しているのにDB接続確立エラーが出てセットアップが進まない。 エラーの対処として以下3点が記載されていた。 「http://VMのIPアドレス:8080」 コンテナ内でvimのインストールとwp-config.phpの編集 エラーの対処としてwp-config.phpにDB接続情報を記載してみたら解決した。 しかしコンテナ内でファイル編集のためにviをするとエラーが発生。 docker exec -it 5200b39bef3a bash vi wp-config.php bash: vi: command not found そこでコンテナ内でvimのインストールの実施 apt-get update apt-get install vim wp-config.phpの編集をして、セットアップが完了しました。 vi wp-config.php 以下の箇所に記載 define( 'DB_NAME', 'wpdb' ); /** MySQL database username */ define( 'DB_USER', 'wpadmin' ); /** MySQL database password */ define( 'DB_PASSWORD', 'xxxxxx' );
- 投稿日：2021-08-29T19:34:33+09:00
【C#】Entity Framework Core で移行したあと、sqlcmdを使ってSQL Serverを観察する
この記事は SQL Server (Docker版)をデータベースファーストで操作してみた記事の続き 前回は、既存のデータベースからモデル（DbContextを継承したクラス）を生成する、いわゆるスキャフォールディングを試した （スキャフォールディングについて書かれた、マイクロソフトのよくわかる記事） 今回はモデルからデータベースを生成する方法、いわゆるコードファーストな方法を試す EF Core で何ができるか 公式ドキュメントから一部引用させていただく EF は、次のモデル開発アプローチをサポートしています。 既存のデータベースからモデルを生成する。 データベースに合わせてモデルのコードを手動で書く。 モデルが作成されたら、EF の移行 を使用して、モデルからデータベースを作成します。 移行により、モデルの変更に応じてデータベースを進化させることができます。 引用元：https://docs.microsoft.com/ja-jp/ef/core/#the-model EF Core 個人的ロードマップ 「既存のデータベースから～」は前回やった 今回はモデルのコードを手動で書いて、そこから移行(Migration)を使ってデータベースをつくるところまでをでやりたい 次回以降があれば、データベースを進化させるを試したい 移行によりDBがどう変化していくか など ソリューションにライブラリプロジェクトを追加する さっそく作業を始める まず最初に、EF Core ドキュメントを参考にして、ライブラリプロジェクトIntroをつくる 今回は、主にこのプロジェクトでの作業となる スタートアッププロジェクトは、前回記事からの続きでWPF_EFCoreをつかう （※ 前回記事ではプロジェクト名まで言及してないかも・・・） 開発者用パワーシェル # プロジェクト作成 dotnet new classlib --framework "netcoreapp3.1" -o Intro # ライブラリプロジェクトをスタートアッププロジェクトの参照に追加 dotnet sln add .\Intro\Intro.csproj dotnet add .\WPF_EFCore\WPF_EFCore.csproj reference .\Intro\Intro.csproj # ライブラリプロジェクトに必要なパッケージをインストール dotnet add .\Intro\Intro.csproj package Microsoft.EntityFrameworkCore dotnet add .\Intro\Intro.csproj package Microsoft.EntityFrameworkCore.SqlServer プロジェクトにインストールしたパッケージを確認する WPF_EFCoreおよびIntroのどちらも .NET Core 3.1 であり、EF Core 5系 が入っている 開発者用パワーシェル dotnet list package # プロジェクト 'WPF_EFCore' に次のパッケージ参照が含まれています # [netcoreapp3.1]: # 最上位レベル パッケージ 要求済み 解決済み # > Microsoft.EntityFrameworkCore.Sqlite 5.0.9 5.0.9 # > Microsoft.EntityFrameworkCore.SqlServer 5.0.9 5.0.9 # > Microsoft.EntityFrameworkCore.Tools 5.0.9 5.0.9 # > Prism.Unity 8.0.0.1909 8.0.0.1909 # # プロジェクト 'Intro' に次のパッケージ参照が含まれています # [netcoreapp3.1]: # 最上位レベル パッケージ 要求済み 解決済み # > Microsoft.EntityFrameworkCore 5.0.9 5.0.9 # > Microsoft.EntityFrameworkCore.SqlServer 5.0.9 5.0.9 なぜ .NET5 ではないのか？ Prism Template Pack から作った空のプロジェクトのデフォルトが .NET Core 3.1 であり そこから .NET 5 に変更するのを忘れたため Introプロジェクトにモデルを追加する 公式ドキュメントのモデルを参考にして、Introプロジェクトにクラスを3つ追加する 接続文字列を自分の環境にあわせる BloggingContextのOnConfiguringメソッドを一部変更する SQL Server DockerコンテナのBloggingデータベースに接続する BloggingContext protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer( + "Data Source=\"localhost, 11433\";Initial Catalog=Blogging;User ID=sa;Password=SqlPass1234"); - @"Server=(localdb)\mssqllocaldb;Database=Blogging;Trusted_Connection=True"); } 接続文字列がベタ書きであることはいけない気がするも、ベストプラクティスが分からない＆テストのため、こう書いている SQLサーバーをたてる コードファーストで書いたモデルをDBに移行するために 移行先となる Docker コンテナの SQL サーバーを起動する Powershell # コンテナを起動する docker start sql1 sql1については、関連する過去の記事を参照 EF Core ツールのコマンドを使って移行する コードファーストでSQLサーバーに新しいDBをつくっていく 具体的には、Visual Studio のパッケージマネージャーコンソールから、EF Core ツールのコマンドを打っていく作業となる 移行というのが、モデルからDBを作成、または変更していくことを表している 前準備 リファレンスを準備して、共通パラメータを確認する EF Core コマンドツールのドキュメント コマンドは10個くらいあるらしい 今回は移行に関するものだけを使う 共通パラメータ 共通パラメータである-Projectを省略すると パッケージマネージャーコンソール の 既定のプロジェクト がターゲットプロジェクトとして使用されます とのこと。 毎回プルダウンから既定のプロジェクトを選びなおしてもいいし あるいは毎回-Projectを指定してもいい また、-V or -Verbose パラメータをつけると、実行中の詳細情報を見ることができる コマンドからエラーが返ってきたときには、エラーの原因を探るために-Vをつけて再度コマンドを打つ 〈本題〉モデルを移行する 3つのコマンドを順番に打って、モデルをDBに移行する Get-DbContext ・・・使用可能なDbContextを取得する Add-Migration ・・・移行を追加する Update-Database ・・・移行をデータベースに反映する 2つ目の「移行を追加する」のイメージが難しいが モデルの変更履歴をセーブポイントとしてローカルに残していくイメージに近いと思う セーブポイントを実際にDBへ反映させるのが、3番目のアップデートになる Get-DbContext 使用可能なDbContextを取得する パッケージマネージャーコンソール Get-DbContext -Project Intro -StartupProject WPF_EFCore # Build started... # Build succeeded. # MyDockerDBContext # BloggingContext スタートアッププロジェクトのMyDockerDBContextと、新規追加したプロジェクトのBloggingContextの2つのコンテキストが表示された 今回使うのは、ライブラリプロジェクトに追加したBloggingContextとなる 以後、-ContextパラメータをつかってBloggingContextを毎回指定する （指定しなかった場合の挙動について、次節で言及する） 〈参考〉Get-DbContextのパラメータを未指定としたときの動作 パラメータを省略すると、スタートアッププロジェクトにあるMyDockerDBContextだけが表示される スタートアッププロジェクトから参照されるライブラリプロジェクトのBloggingContextは表示されない パッケージマネージャーコンソール Get-DbContext # Build started... # Build succeeded. # MyDockerDBContext Add-Migration 移行を追加する 最初の移行は、DBの新規作成に相当する その次からの移行は、1つ前の移行からの差分が記録される パッケージマネージャーコンソール Add-Migration -Name Init -Context BloggingContext -Project Intro -StartupProject WPF_EFCore # Build started... # Build succeeded. # To undo this action, use Remove-Migration. Introプロジェクトに新しくMigrationsフォルダが生成される 以後、Add-Migrationをするたびに、移行履歴が記録されていく 移行の挙動については、また別の記事で試す予定 DbContextが複数ある場合は-Contextを省略してはいけない Get-DbContextで確認したときにDbContextが2個あったので -Contextパラメータで使うコンテキストを指定しないと、エラーが発生する パッケージマネージャーコンソール # -Context 引数を省略した Add-Migration -Name Init -Project Intro -StartupProject WPF_EFCore More than one DbContext was found. Specify which one to use. Use the '-Context' parameter for PowerShell commands and the '--context' parameter for dotnet commands. 〈意訳〉 2つ以上のDbContextが見つかったよ。どっちを使うか決めてね。Powershellをつかっている人は-Contextパラメータを使うといいよ。 Update-Database 移行をデータベースに反映する 何も指定しなければ、最後の移行が反映される パッケージマネージャーコンソール Update-Database -Project Intro -Context BloggingContext # Build started... # Build succeeded. # Applying migration '202108********_Init'. Add-Migrationを繰り返すと移行先が複数になる 移行先を選択したい場合は、-Migrationで指定する パッケージマネージャーコンソール Update-Database -Project Intro -Context BloggingContext -Migration Init -StartupProject WPF_EFCore # Build started... # Build succeeded. # No migrations were applied. The database is already up to date. # Done. すでに移行が完了しているので、「DBはup to dateされている」と表示された データベースを確認する ここまでの変更がDBに反映されていることを確認する SQL Server (Dokcerコンテナ)に入る 移行作業の前にsql1（Docker版SQLサーバー）をスタートさせているので、その中に入る Powershell # コンテナに入る docker exec -it sql1 "bash" SQL Serverにログインする localhostにユーザIDsaでログインする パスワードを聞かれるので入力する bash # DBサーバーにログインする。 /opt/mssql-tools/bin/sqlcmd -S localhost -U sa -W -Wオプションをつけると、画面への出力が整形されてイイ感じになる（参考にさせていただいた記事） DB一覧を取得する 既存のDBに加えて、Bloggingデータベースが新たに追加されている sqlcmd 1> SELECT name FROM sys.databases; 2> GO name ---- master tempdb model msdb + Blogging 作業するデータベースをBloggingにする 作業するデータベースをUSEで指定する 使うのはもちろんBloggingデータベース sqpcmd 1> USE Blogging; 2> GO Changed database context to 'Blogging'. 今いるデータベースの名前を取得すると、Bloggingと表示される sqpcmd 1> SELECT DB_NAME(); 2> GO - Blogging ちなみに自分の環境では、デフォルトはmasterだった テーブル一覧を取得する TYPE = 'U'のテーブル一覧を取得する TYPEを指定しないと、たくさんのテーブルが表示される sqpcmd 1> SELECT * FROM sys.objects WHERE TYPE = 'U'; 2> GO name object_id principal_id schema_id parent_object_id type type_desc create_date modify_date is_ms_shipped is_published is_schema_published ---- --------- ------------ --------- ---------------- ---- --------- ----------- ----------- ------------- ------------ ------------------- __EFMigrationsHistory 885578193 NULL 1 0 U USER_TABLE ... Blogs 917578307 NULL 1 0 U USER_TABLE ... Posts 949578421 NULL 1 0 U USER_TABLE ... 3つのテーブルが表示された BlogsテーブルとPostsテーブルは 移行した際にコンテキストに含まれていたDbSet<Blog> BlogsとDbSet<Post> Postsである __EFMigrationsHistoryは、その名からして、移行履歴を保持しているテーブルらしい __EFMigrationsHistoryの中を覗いてみる 1> SELECT * FROM __EFMigrationsHistory; 2> GO MigrationId ProductVersion ----------- -------------- 202108********_Init 5.0.9 (1 rows affected) MigrationIdとProductVersionの2つのフィールドが存在する MigrationIdはAdd-Migrationしたときに生成された.csファイルの名前と一致しており 一方のProductVersionは EF Core のバージョンと一致している テーブルのフィールドを確認する 1> SELECT * FROM Blogs; 2> GO BlogId Url Rating ------ --- ------ Blogsテーブルには、モデルで指定した3つのフィールドが存在する List<Post>のPostsフィールドは存在しない 1> SELECT * FROM Posts; 2> GO PostId Title Content BlogId ------ ----- ------- ------ Postsテーブルには、モデルで指定した4つのフィールドが存在する Blog型のBlogフィールドは存在しない いずれれもstringやintなどのプリミティブ型のみがテーブルのフィールドに反映されて ListやBlogなどの集約関係や実態などはテーブルには反映されていないことがわかる マイグレーションしたときのコード Initクラスから一部抜粋 protected override void Up(MigrationBuilder migrationBuilder) { migrationBuilder.CreateTable( name: "Blogs", columns: table => new { BlogId = table.Column<int>(type: "int", nullable: false) .Annotation("SqlServer:Identity", "1, 1"), Url = table.Column<string>(type: "nvarchar(max)", nullable: true), Rating = table.Column<int>(type: "int", nullable: false) }, constraints: table => { table.PrimaryKey("PK_Blogs", x => x.BlogId); }); migrationBuilder.CreateTable( name: "Posts", columns: table => new { PostId = table.Column<int>(type: "int", nullable: false) .Annotation("SqlServer:Identity", "1, 1"), Title = table.Column<string>(type: "nvarchar(max)", nullable: true), Content = table.Column<string>(type: "nvarchar(max)", nullable: true), BlogId = table.Column<int>(type: "int", nullable: false) }, constraints: table => { table.PrimaryKey("PK_Posts", x => x.PostId); table.ForeignKey( name: "FK_Posts_Blogs_BlogId", column: x => x.BlogId, principalTable: "Blogs", principalColumn: "BlogId", onDelete: ReferentialAction.Cascade); }); migrationBuilder.CreateIndex( name: "IX_Posts_BlogId", table: "Posts", column: "BlogId"); } おわりに 今回は、モデルからDBを作成するとこまでを試した 次は、実際にデータを入れて、さらにテーブルの構造を変えてみたりして EF Core & SQL Serverの挙動を理解したい SQL Serverの操作に関して、参考にさせていただいた記事 関連する過去の記事
- 投稿日：2021-08-29T19:24:52+09:00
家のネットワークを監視することにした
家のネットワークが遅い気がする ネットワークが遅い気がする．切れたりする． ルータまでは接続できるがその先に行けない． とりあえず監視することにした． とりあえず監視するツールを調べた Zabbix 無料 docker image が提供されている 今回は，ローカルホストから監視できると良さそう． external script でもいいかも． zabbix-server に speedtest コマンドインストールするのが面倒な気がしたので，今回は別イメージにした． cron 設定をコードに落としておきたいので，docker compose ならその配下で実行できることが望ましい． 手順 - Zabbix 起動するまで Refers に乗せてあるものと同じだが，一応 $ cp docker-compose_v3_alpine_mysql_latest.yaml docker-compose.yaml $ edit .env_web # PHP_TZ=Asia/Tokyo を追加 $ docker compose up -d これだけで，http://localhost にアクセスできるようになる． (ログイン情報は，公式参照 とはいえ，80 番ポートを使われると面倒なので，修正． diff --git a/docker-compose.yaml b/docker-compose.yaml index 7eb3b1c0..7299bcac 100644 --- a/docker-compose.yaml +++ b/docker-compose.yaml @@ -229,8 +229,8 @@ services: zabbix-web-nginx-mysql: image: zabbix/zabbix-web-nginx-mysql:alpine-5.4-latest ports: - - "80:8080" - - "443:8443" + - "12080:8080" + - "12443:8443" volumes: - /etc/localtime:/etc/localtime:ro - /etc/timezone:/etc/timezone:ro これで，http://localhost:12080 にアクセスできるようになる 手順 - cron を設定する docker で cron を動かす コチラ の記事を参考にさせて頂いた． diff --git a/docker-compose.yaml b/docker-compose.yaml index 7299bcac..882b3aad 100644 --- a/docker-compose.yaml +++ b/docker-compose.yaml @@ -459,6 +459,16 @@ services: # aliases: # - elasticsearch + cron: + build: + context: cron + depends_on: + - zabbix-server + + cron/Dockerfile FROM ubuntu:20.10 RUN apt update && \ apt install -y cron COPY sender_speedtest.sh /usr/local/bin/ COPY speedtest /etc/cron.d/speedtest RUN chmod 0644 /etc/cron.d/speedtest CMD ["cron", "-f"] speedtest * * * * * root /usr/local/bin/sender_speedtest.sh sender_speedtest.sh #!/bin/bash touch /tmp/speedtest.log /tmp/speedtest.err date >> /tmp/speedtest.log 2>> /tmp/speedtest.err 新しいイメージを起動する $ docker compose build $ docker compose up -d up だけでrecreate してくれるのね．便利… 動作確認する．ログにデータが入っていればOK． $ docker compose exec cron bash # tail -f /tmp/speedtest.* 手順 - zabbix send する cron でやろうとして，よく考えたら zabbix から external script とかで取った方がいいのかも？と思ったけど， Refers の記事によると，sender で良さそうだったので，sender にする． まず speedtest が動くようにする 必要なソフトを cron 用イメージに追加． speedtest zabbix-sender cron/Dockerfile FROM ubuntu:20.10 RUN apt update && \ apt install -y cron curl RUN curl -s https://install.speedtest.net/app/cli/install.deb.sh | bash && \ curl -LO https://repo.zabbix.com/zabbix/5.4/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.4-1+ubuntu20.04_all.deb && \ dpkg -i zabbix-release_5.4-1+ubuntu20.04_all.deb && \ rm zabbix-release_5.4-1+ubuntu20.04_all.deb && \ apt update && \ apt install -y speedtest zabbix-sender COPY sender_speedtest.sh /usr/local/bin/ COPY speedtest /etc/cron.d/speedtest RUN chmod 0644 /etc/cron.d/speedtest CMD ["cron", "-f"] スクリプトを修正． sender_speedtest.sh #!/bin/bash SPEEDTEST_SERVER_ID=`/usr/bin/speedtest -L | grep -E "OPEN Project" | sed 's/^ *\| *$//' | cut -d " " -f 1` if [ -z "$SPEEDTEST_SERVER_ID" ]; then SPEEDTEST_SERVER_ID=`/usr/bin/speedtest -L | tail -1 | sed 's/^ *\| *$//' | cut -d " " -f 1` fi SPEEDTEST_RESULT=`/usr/bin/speedtest --accept-license -s $SPEEDTEST_SERVER_ID -f json` ZABBIX_SERVER=zabbix-server ZABBIX_HOSTNAME=speedtest.net ZABBIX_ITEMKEY=speedtest.json /usr/bin/zabbix_sender -z $ZABBIX_SERVER -s $ZABBIX_HOSTNAME -k $ZABBIX_ITEMKEY -o "$SPEEDTEST_RESULT" 接続先に OPEN Project が居なくなったりするので，最後のを使うようにした． それと，license にaccept しないといけないので引数に追加した． send したり，speedtest を実行するためにネットワーク設定が必要そうだったので追加した． diff --git a/docker-compose.yaml b/docker-compose.yaml index 7299bcac..882b3aad 100644 --- a/docker-compose.yaml +++ b/docker-compose.yaml @@ -459,6 +459,16 @@ services: # aliases: # - elasticsearch + cron: + build: + context: cron + depends_on: + - zabbix-server + networks: + zbx_net_backend: + zbx_net_frontend: + + テスト用に，1分おきにしていたのを，5分おきに修正 speedtest */5 * * * * root /usr/local/bin/sender_speedtest.sh で，新しいイメージを起動する． $ docker compose build $ docker compose up -d これで動いてそう．しばらく様子を見る． (send するには，zabbix 側に trapper アイテム登録も必要なので，参考にした記事 を参照のこと 接続ができるようになるまでは，`bash -x /usr/local/bin/send_spedtest.sh` を実行してログを見たりしていた 結局，トラッパーアイテムのkey のタイポだったことを記載しておく Refers
- 投稿日：2021-08-29T15:50:46+09:00
DockerのReact環境構築を詳細に解説する
なぜこの記事を書いたのか 「Dockerfile と docker-compose.ymlを一から作成してビルドする」一連の流れをこれまでにしたことがなかったので、学習がてら環境構築をして、この記事にもアウトプットすることにした。 環境構築完了（ゴール）の確認 この記事のゴールは以下のようにReactのページが起動すること。 環境構築の手順 ①Docker、nodeのインストール ②Dockerfile、docker-compose.ymlの作成 ③ビルド ④Reactアプリの作成 ⑤コンテナの実行 ①Docker、nodeのインストール Dockerのインストール https://www.docker.com nodeのインストール https://nodejs.org/ja/download/ ②Dockerfile、docker-compose.ymlの作成 docker-react-app（プロジェクトフォルダ） └┬─ Dockerfile └─ docker-compose.ymlの 上記のフォルダ構成で、フォルダとファイルを任意の場所へ作成する。 Dockerfileの作成 FROM node:14.17.5 WORKDIR /usr/src/app/ node:〇〇の”〇〇”は「node --version」でnodeバージョンを確認して記述する。上記でnodeをインストールしていれば、バージョンを取得できる。 docker-compose.ymlの作成 docker-compose.yml version: '3' services: node: build: context: . tty: true environment: - NODE_ENV=development volumes: - ./:/usr/src/app command: sh -c "cd reactapp && npm start" ports: - "3000:3000" ③ビルド docker-compose build ④Reactアプリの作成 docker-compose run --rm node sh -c "npm install -g create-react-app && create-react-app reactapp" ⑤コンテナの実行 docker-compose up ここまで完了したらWebブラウザで「 http://localhost:3000 」へアクセスする。以下のようにReactのページが起動すれば環境構築完了となる。
- 投稿日：2021-08-29T14:08:33+09:00
DockerでNuxt.jsとExpressの環境構築を行うよ
はじめに 今回はNuxt.jsとExpressの環境をDockerで作成した記事です。 環境 今回は、Nuxt.jsにTypeScriptを導入し、Composition-APIの書き方を採用します。 また、バックエンドにはORMとしてPrismaを採用します。 Prismaの導入に関してものすごく手間取りました。 Qiitaで質問にお答えいただいた2名の方に感謝申し上げます。 Dockerfile MySQL (5.7) Node.js （【Express】14.15.3-alpine） Node.js （【Nuxt.js】14.15.3-alpine） Frontend 採用する技術は以下の通りです。 Nuxt.js TypeScript Vue3.0（Composition-API） Composition-APIに関して全く知識がない方は以下の記事をご覧ください。 Backend 採用する技術は以下の通りです。 Express TypeScript Prisma Github コードはこちらです。 READMEに環境構築の方法を書いてますが、Qiitaにまとめてみます。 それでは環境を作りましょう〜！ ①クローンしてディレクトリを移動する ターミナル $ git clone git@github.com:ssk9597/Docker-Nuxt-TypeScript-Express-Prisma.git $ cd Docker-Nuxt-TypeScript-Express-Prisma ②作成するテーブルを記載する api/prisma/schema.prismaに現在デフォルトで以下が記載されています。 api/prisma/schema.prisma model User { id Int @id @default(autoincrement()) name String email String @unique } 上記の意味は、以下の通りです ①Userテーブルを作成 ②カラムは3つ ③idというカラムは数値型で、オートインクリメントになっている ④nameというカラムは文字列型になっている ⑤emailというカラムは文字列型でユニークになっている リレーションなどもできるので詳しくは公式サイトを確認しましょう。 ③make nuxtを実行して、Nuxt.jsの作成とDockerの起動を行う Nuxt.jsの作成では、必ずTypeScriptを選択してください。 ターミナル $ make nuxt > npx create-nuxt-app frontend create-nuxt-app v3.6.0 ✨ Generating Nuxt.js project in frontend ? Project name: nuxt-typescript ? Programming language: TypeScript ? Package manager: Npm ? UI framework: None ? Nuxt.js modules: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? Linting tools: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? Testing framework: None ? Rendering mode: Universal (SSR / SSG) ? Deployment target: Server (Node.js hosting) ? Development tools: (Press <space> to select, <a> to toggle all, <i> to invert selection) ? What is your GitHub username? XXXXX ? Version control system: Git ④nuxt.config.jsと.envを修正する nuxt.config.js frontend/nuxt.config.js require('dotenv').config(); const { API_URL, API_URL_BROWSER } = process.env; export default { head: { title: 'frontend', htmlAttrs: { lang: 'ja', }, meta: [ { charset: 'utf-8' }, { name: 'viewport', content: 'width=device-width, initial-scale=1' }, { hid: 'description', name: 'description', content: '' }, ], link: [{ rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' }], }, css: [], plugins: [], components: true, buildModules: ['@nuxt/typescript-build'], watchers: { webpack: { poll: true, }, }, modules: ['@nuxtjs/axios', '@nuxtjs/proxy', '@nuxtjs/dotenv'], env: { API_URL, API_URL_BROWSER, }, proxy: { '/api': process.env.API_URL, }, axios: { baseURL: process.env.API_URL, browserBaseURL: process.env.API_URL_BROWSER, }, build: {}, }; .env frontend/.env API_URL = "http://app:18080" API_URL_BROWSER = "http://localhost:18080" ⑤make migrateでPrismaのマイグレーションを行う ターミナル $ make migrate こちらの実行でマイグレーションとGUIでデータベース上のデータを閲覧・編集できるPrisma studioが使用できるようになります。 これがめちゃんこ便利です！ ⑥make typescriptでTypeScriptを導入する まずはターミナルで必要なパッケージをインストールしましょう。 ターミナル $ make typescript 次に必要なファイルに追記を行います。 shims-vue.d.ts frontend/shims-vue.d.ts declare module '*.vue' { import Vue from 'vue'; export default Vue; } tsconfig.json frontend/tsconfig.json { "compilerOptions": { "target": "ES2018", "module": "ESNext", "moduleResolution": "Node", "lib": ["ESNext", "ESNext.AsyncIterable", "DOM"], "esModuleInterop": true, "allowJs": true, "sourceMap": true, "strict": true, "noEmit": true, "experimentalDecorators": true, "baseUrl": ".", "paths": { "~/*": ["./*"], "@/*": ["./*"] }, "types": ["@nuxt/types", "@types/node"] }, "files": ["shims-vue.d.ts"], "include": [ "components/**/*.ts", "components/**/*.vue", "layouts/**/*.ts", "layouts/**/*.vue", "pages/**/*.ts", "pages/**/*.vue" ], "exclude": ["node_modules", ".nuxt", "dist"] } これでTypeScriptが使えます。 ⑦make composition-apiでComposition-APIを導入する まずはターミナルで必要なパッケージをインストールしましょう。 ターミナル $ make composition-api 次に必要なファイルに追記を行います。 nuxt.config.js frontend/nuxt.config.js require('dotenv').config(); const { API_URL, API_URL_BROWSER } = process.env; export default { head: { title: 'frontend', htmlAttrs: { lang: 'ja', }, meta: [ { charset: 'utf-8' }, { name: 'viewport', content: 'width=device-width, initial-scale=1' }, { hid: 'description', name: 'description', content: '' }, ], link: [{ rel: 'icon', type: 'image/x-icon', href: '/favicon.ico' }], }, css: [], plugins: [], components: true, buildModules: ['@nuxt/typescript-build', '@nuxtjs/composition-api/module'], generate: { interval: 2000, }, watchers: { webpack: { poll: true, }, }, modules: ['@nuxtjs/axios', '@nuxtjs/proxy', '@nuxtjs/dotenv'], env: { API_URL, API_URL_BROWSER, }, proxy: { '/api': process.env.API_URL, }, axios: { baseURL: process.env.API_URL, browserBaseURL: process.env.API_URL_BROWSER, }, build: {}, }; ⑧pages/index.vueを修正してバックエンドとの通信を図る では、バックエンドとの通信ができているか確認しましょう。 frontend/pages/index.vue <template> <div> <h1> {{ data }} </h1> </div> </template> <script lang="ts"> import { defineComponent, ref, useAsync, useContext } from '@nuxtjs/composition-api'; import axios from '@nuxtjs/axios'; export default defineComponent({ setup() { const data = ref({}); const { $axios } = useContext(); useAsync(async () => { const result = await $axios.$get('/api'); data.value = result; }); return { data }; }, }); </script> このように表示されていれば問題なく通信ができています！ また、Prismaのクエリに関してはこちらを確認してください。 基本のCRUDに関してはまとめてあるのでこれを使いこなせれば問題ないと思います。 ここからは任意です UI開発用ツールのStorybookを使いたい方は以下も行うようにしましょう。 ちなみに、Storybookが何か分からない方は以下の記事を確認されてください。 コマンド1つでStorybookが実行できます。 ターミナル $ make storybook // 再起動したいとき $ make re-storybook 終わりに ここまでできればNuxt.jsとExpressの環境構築はばっちりです? あとは作りたいものを作っていきましょう！
- 投稿日：2021-08-29T13:59:04+09:00
開発環境のRailsアプリをDockerコンテナで起動してみた
目次 1.はじめに 2.前提 3.大まかな手順 4.dockerの設定ファイル作成 5.アプリ用コンテナとデータベース用コンテナの接続設定 6.コンテナ起動 7.まとめ はじめに 先日、Railsで学習系のWebアプリを作成しましたが、環境構築の際は、何かしらエラーが出ては原因を調べて解消の繰り返しでした。様々な知識を得る良い機会ではあったのですが、今後、開発をする際はより効率的にできたらなという思いがあります。解決手段の１つとしては「Docker」が挙げられるかと思います。次にアプリ開発をする際は初期段階からDockerを用いた開発をしたいと考えていますが、まずは今回作成した既存のアプリをDockerコンテナで起動できないか試してみましたので、記録として残します。 前提 ・開発端末にてDockerをインストール済であること ・以下の手順における各ソフトウェアバージョンは次の通り ・Ruby: 2.6.5 ・Rails: 6.0.3 ・MySQL: 5.6 ・今回は既存アプリを2種類のDockerコンテナ(アプリ用コンテナ、データベース用コンテナ)を連携させて起動する 大まかな手順 ①dockerの設定ファイル(Dockerfileとdocker-compose.yml)作成 ②アプリ用コンテナとデータベース用コンテナの接続設定 ③コンテナ起動 dockerの設定ファイル作成 まずは既存アプリのフォルダ階層にて以下、2種類のファイルを作成します。 ■ Dockerfile →Dockerイメージの素となるファイル。ここに記述された内容で、まるっと環境のイメージが生成されます。今回はアプリ用コンテナの素となるように記述していきます。 ■ docker-compose.yml →複数のコンテナを管理する際に使用するファイル。今回はアプリ用コンテナとデータベース用コンテナの定義を記述して管理します。 ファイルを作成したら各々に定義を記述していきます。 ※ 各行で何をしているかはコメントを参照 ■ Dockerfileの内容 #アプリ用コンテナの素 #以下、「memory_tank」の部分は適宜、自分のアプリ名にする #ベースとなるバージョン2.6.5のrubyイメージを公式リポジトリより取得 FROM ruby:2.6.5 #コンテナ内のパッケージ管理を最新状態にする #前提ソフトウェア(nodejs、mysql)や保守用にvimをインストール。「--no-install-recommends」オプションを付け、recommendされた不要なソフトウェアはインストールしない #イメージ軽量化のためにapt-getリストをクリア RUN apt-get update && \ apt-get install -y nodejs default-mysql-client vim --no-install-recommends && \ rm -rf /var/lib/apt/lists/* #アプリ用ディレクトリの作成 RUN mkdir /memory_tank #ワークディレクトリを設定 WORKDIR /memory_tank #ローカルのGemfileをアプリ用コンテナにコピーする ADD Gemfile /memory_tank/Gemfile ADD Gemfile.lock /memory_tank/Gemfile.lock #アプリ用コンテナにgemをインストール RUN gem install bundler RUN bundle install #ローカルのアプリファイルをまるっとアプリ用コンテナにコピー ADD . /memory_tank ■ docker-compose.ymlの内容 docker-compose.yml version: "2" services: db: #データベース用コンテナの定義 image: mysql:5.6 #ベースとなるバージョン5,6のmysqlイメージを公式リポジトリより取得 command: mysqld --character-set-server=utf8 --collation-server=utf8_unicode_ci #文字コードの設定 environment: MYSQL_ROOT_PASSWORD: ****** #データベースユーザ「root」のパスワード MYSQL_DATABASE: memory_tank_development #データベース名 volumes: - mysql-data:/var/lib/mysql #名前付きボリュームでデータを永続化 ※ Dockerの管理下にデータを保管 ports: - "3306:3306" #ポート設定 app: #アプリ用コンテナの定義 build: . #DockerFileを素にコンテナイメージを作成 command: /bin/sh -c "rm -f tmp/pids/server.pid && bundle exec rails s -p 3000 -b '0.0.0.0'" #railsの起動 volumes: - .:/memory_tank #ローカルのディレクトリをコンテナにマウント - bundle:/usr/local/bundle #bundle install後のbuildを不要にするため ports: - "3000:3000" #ポート設定 depends_on: #作成順序の設定 「db」→「app」 - db volumes: mysql-data: #名前付きボリューム bundle: #bundle install後のbuildを不要にするため アプリ用コンテナとデータベース用コンテナの接続設定 次にアプリ用コンテナとデータベース用コンテナが正常に通信できるよう、「database.yml」を編集します。 ※ socket通信でのDB接続ではなく「host：db」のように、データベース用コンテナを直接指定します。 docker-compose.yml default: &default adapter: mysql2 encoding: utf8 pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %> username: root password:***** host: db #データベース用コンテナを指定 コンテナ起動 ここまでで各種定義が完了したため、最後にコンテナをバックグラウンドで起動して稼働確認を行います。 xxxx@xxxxnoMacBook-Pro memory_tank % docker-compose up -d Starting memory_tank_db_1 ... done Starting memory_tank_app_1 ... done xxxx@xxxxnoMacBook-Pro memory_tank % 「localhost:3000」でアプリに接続できることを確認 まとめ 今回の作業を通し、ある程度はDockerについての基礎知識が身についてきたため、今後はwebアプリ初期段階でのDocker導入やAWS ECSへの本番デプロイに繋げていけたらと思います。 以上、最後まで読んで頂きありがとうございました！
- 投稿日：2021-08-29T10:52:16+09:00
GitHub Codespaces で自前イメージを使う
この記事は GitHub Codespaces では、その環境をユーザがカスタマイズできます。 この記事ではカスタマイズのための全体の流れの例を説明します。具体的なカスタマイズの詳細については触れません。 自前イメージへの切り替え GitHub Actions によるイメージ生成および GitHub Container Registry への配置 GitHub Container Registry に置いたイメージを使った Codespaces 起動 あたりについて書きます。 おことわり 私は普段 VS Code を使っておらず、(Codespaces と基本は同じと思われる) VS Code Remote + devcontainer でのノウハウも特に持っていません。的外れなことを書いていたらごめんなさい。 手順 リポジトリに基本となる .devcontainer/ を置く Codespaces を使うリポジトリのルートに .devcontainer/ を置きます。 まずは、標準の Codespaces で使われているコンテナ定義を使うのが良いでしょう。 の .devcontainer/ をコピーすれば OK です。 あるいはより簡素な も良いと思います。 ファイルの説明 vscode-dev-containers で提供されている .devcontainer/ は以下のような構成になっているようです。 devcontainer.json 大元の定義ファイル ここにどの Dockerfile が使われるかが指定されている Dockerfile 実際に Codespaces 起動に使われるのはこれ 実質1行。生成済みイメージが FROM でベースイメージに指定されている 簡単な変更ならこのファイルに追加すればよい base.Dockerfile Dockerfile の FROM に書かれている生成済みイメージを生成するための Dockerfile と思われる (そのままでは) 実際の Codespaces 起動時には使われない よりきめ細かく変更したいなら、これを変更してイメージ生成する (今回はこちら) その他ヘルパースクリプトなど Dockerfile はこんな感じです。コメントにあるように、パッケージの追加程度ならこれを変更すれば良いでしょう。 FROM mcr.microsoft.com/vscode/devcontainers/universal:1-linux # ** [Optional] Uncomment this section to install additional packages. ** # USER root # # RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \ # && apt-get -y install --no-install-recommends <your-package-list-here> # # USER codespace そのまま Codespaces 起動してみる まずはそのまま Codespaces を起動してみます。 デフォルトと同じ環境が10-20秒ほどで起動するはずです。 起動時にイメージをビルドする 次に、base.Dockerfile を使うように devcontainer.json を変更して commit & push します。 diff --git a/containers/codespaces-linux/.devcontainer/devcontainer.json b/containers/codespaces-linux/.devcontainer/devcontainer.json index 7a6605c2..b0acd62e 100644 --- a/containers/codespaces-linux/.devcontainer/devcontainer.json +++ b/containers/codespaces-linux/.devcontainer/devcontainer.json @@ -1,7 +1,7 @@ { "name": "GitHub Codespaces (Default)", "build": { - "dockerfile": "Dockerfile" + "dockerfile": "base.Dockerfile" }, "settings": { "go.toolsManagement.checkForUpdates": "local", Codespaces を起動してみます。同じ環境が起動しますが、今度は起動時にイメージのビルドが行われるので、10-20分ぐらいかかるはずです。 これでは実用に耐えませんね。 GitHub Actions を使ってイメージをビルド & GitHub Container Registry に置く Codespaces を起動するたびにイメージをビルドするのはつらいので、予め GitHub Actions でビルドしておくことにします。 以下は main ブランチの .devcontainer/ が変更されたことをトリガーとして イメージをビルドして GitHub Container Registry に push する ための GitHub Actions の定義です。この例だと ghcr.io/ユーザ名/リポジトリ名/codespace:latest に push されます。 お好みに合わせて適当に変更してください。 このファイルを commit & push した後で、試しに .devcontainer/ 以下にファイルを追加するなどして GitHub Actions を走らせてみましょう。 .github/workflows/build-codespace-image.yml name: Create and publish a Docker image for Codespaces on: push: branches: - main paths: - '.devcontainer/**' env: REGISTRY: ghcr.io jobs: build-and-push-image: runs-on: ubuntu-latest permissions: contents: read packages: write steps: - name: Checkout repository uses: actions/checkout@v2 - name: Log in to the Container registry uses: docker/login-action@v1 with: registry: ${{ env.REGISTRY }} username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} - name: Build and push Docker image uses: docker/build-push-action@v2 with: context: .devcontainer/ file: .devcontainer/base.Dockerfile push: true tags: ${{ env.REGISTRY }}/${{ github.repository }}/codespace:latest GitHub の Personal Access Token を生成する Codespaces が GitHub Container Registry に置いたイメージを取得できるように、アクセス権を付与する必要があります。(同じ GitHub なんだからこの設定なしでやってくれてもいい気もしますが) のドキュメントを参考にしつつ、 https://github.com/settings/tokens からトークンを生成します。付与するスコープ(権限) は read:packages だけで OK です。ここで表示される値はこのあとすぐに Codespaces 用設定に登録するので、ブラウザのタブはそのままにしておきましょう。 GitHub Container Registry にアクセスするための情報を Codespaces の Secret に登録する https://github.com/settings/codespaces の「Codespaces secrets」から Secret を3つ登録します。 GHCR_CONTAINER_REGISTRY_SERVER : ghcr.io GHCR_CONTAINER_REGISTRY_USER : GitHubアカウント名 GHCR_CONTAINER_REGISTRY_PASSWORD : 先ほど生成した Personal Access Token この GHCR の部分は共通になっていればなんでも OK のようです。それぞれ、 Codespaces を利用したいリポジトリから使えるように選択しておきます。 このあたりについての公式ドキュメントはこちら。 GitHub Container Registry に置いたイメージを使う GitHub Container Registry に置いたイメージを指定する Dockerfile を用意します。 .devcontainer/Dockerfile.ghcr FROM ghcr.io/ユーザ名/リポジトリ名/codespace:latest devcontainer.json を変更します。 diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index b0acd62..17290a7 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -1,7 +1,7 @@ { "name": "GitHub Codespaces (Default)", "build": { - "dockerfile": "base.Dockerfile" + "dockerfile": "Dockerfile.ghcr" }, "settings": { "go.toolsManagement.checkForUpdates": "local", Codespaces を起動すると、今度は GitHub Container Registry からイメージを取得して 30秒-1分程度で起動するはずです。 イメージをカスタマイズ これでひととおり CI/CD のパスが通りました。あとは base.Dockerfile をいじってイメージをカスタマイズしていきましょう。 まとめ GitHub Codespaces の環境をカスタマイズするためのステップ例を紹介しました。 GitHub Actions を使ってイメージを GitHub Container Registry におき、それを使うことで Codespaces 起動を高速化できます。
- 投稿日：2021-08-29T01:05:07+09:00
1分で環境立上げ - create-react-app & typescript & yarn & dockerを実行するまで
Issue create-react-app & typescriptでアプリが完成したが、良さそうなDockerfileとdocker-compose.ymlが無い。 解決策 過去のプロジェクトからとってきた。 今後検索で引っ掛かるようにここで共有する。 前提 Dockerfileとdocker-composeの知識がある前提なので、わからなければ公式サイトで勉強することを勧める。 CRAはEjectしていない前提である。 実装 Dockerfile FROM node:14-alpine AS builder # set working directory WORKDIR /app # Copies package.json and yarn.lock to Docker environment COPY package.json ./ COPY yarn.lock ./ # Install `serve` to run the application. RUN npm install -g serve # Installs all node packages RUN yarn install --frozen-lockfile # Copies everything over to Docker environment COPY . . # Build for production. RUN yarn build # Uses port which is used by the actual application EXPOSE 5000 # Run application #CMD [ "npm", "start" ] CMD serve -s build docker-compose.yml version: "3" services: my_webapp: build: context: . volumes: - ./src:/app/src # 多分これはいらないかも。 ports: - "5000:5000" あとは、以下のコマンドでローカルと本番環境で実行できる。 docker-compose build -> ビルドを作る docker-compose up -d -> バックグラウンドで実行する Portの設定は<HOST>:<CONTAINER>になる。なので、- "5000:5000"の後の部分を変えずに最初の部分だけをホストマシンのポートに設定する。後の部分を変えるのであれば、DockerfileのEXPOSE 5000と同じ値である必要がある。 以上。 ハッピーコーディング！
- 投稿日：2021-08-29T00:19:03+09:00
VSCode リモートコンテナの Python3.8 にnvm , nodeのインストールをDockerファイルに記述する
リモートコンテナ用のdockerイメージ（Debian11, Python3.8）の環境でnodeを使いたかったので入れた いろんなOSさわると、遭遇するエラーもさまざま 入れた対象OS root ➜ /workspaces $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Dockerファイルに記載してnvmとnodeをインストール（Rebuild Containerで実行して1分かからず） 操作しているユーザー環境変数の設定はしていない apt upgrade はしなくても良い node install ではビルドしない（-s 指定しない） install.sh が実行されると、/usr/local/share/nvm に nvmが入っていることを気づかずにやっていてつまづいた 作成したDeockerfile（https://gist.github.com/ssugimoto/acd7fe5d25b9adaf149dd3c8a3bdbf2a ）、以下も同じ FROM mcr.microsoft.com/vscode/devcontainers/python:3.8 RUN apt-get update \ && apt-get -y install curl \ && apt-get autoremove -y \ && apt-get clean -y \ RUN apt-get upgrade \ && apt-get -y install curl ENV NVM_DIR /usr/local/share/nvm ENV NODE_VERSION 12.22.1 # # Install nvm with node and npm RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash \ && . $NVM_DIR/nvm.sh \ && nvm install $NODE_VERSION \ && nvm alias default $NODE_VERSION \ && nvm use default WORKDIR /workspaces 入れたバージョンの確認 root ➜ /workspaces/test $ root ➜ /workspaces/test $ nvm --version 0.38.0 root ➜ /workspaces/test $ node --version v12.22.1 root ➜ /workspaces/test $ npm --version 6.14.12 root ➜ /workspaces/test $ python --version Python 3.8.11 エラーの対応 /bin/sh: nvm: not found docker , "bash: nvm: command not found" nvm コマンドがありません。 手動でインストールすると発生しないけど、Dockerfileだと発生する RUN コマンド１行で（まとめて）記載する必要があるんだけど、１行で記載しても解決できず。 そもそもnvmがインストールされる場所が想定と違ってた 参考 その１） https://zenn.dev/uttk/articles/a7b085c7774ae9 こちらでは、alpine linux のため少し異なる。環境変数適用が違う。Ubuntuの記載がある。 その２）https://stackoverflow.com/questions/25899912/how-to-install-nvm-in-docker こちらの stack overflowを参考にしました その３）https://gist.github.com/remarkablemark/aacf14c29b3f01d6900d13137b21db3a#file-dockerfile こちらも 参考にしました。ディスカッションが最もあり参考になる。 debianでのDockerファイルにnvm installを記載する例、ここでも /usr/local/nvm のパスで自身の環境とは一致しなかった ENV NVM_DIR /usr/local/nvm ・・・ . $NVM_DIR/nvm.sh の２つの箇所、 /usr/local/nvm にはインストールされないので変更が必要 なぜ、node用のリモートコンテナを使わないのか VSCodeリモートコンテナ Debian10 node12（node12または14）の環境が入っているOS Debian10ではPython3.7がインストール済で、Python3.8 を sudo apt-get install python3.8 ではインストールできなかった Pyhon3.8を使うには いくつかの xxx-devライブラリを入れ、 make altinstall する必要があり、コンテナが使えるまでの時間が長すぎた Dockerファイルに書かないで、通常のインストール ほぼ、以下のコマンド入る（sudo ついてるけど、rootで作業しています） # sudo apt update # sudo apt upgrade # sudo apt-get install curl nvm のインストール # curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.35.2/install.sh | bash # nvm --version # nvm install v12.22.1 コンテナビルドに続いて Amplif cli 入れたら３分くらいかかった（176sec） devcontainer.json に "postCreateCommand": "npm install -g @aws-amplify/cli@5.3.1", を追記した場合に、npm install が3分かかった npm install ログの最後 + @aws-amplify/cli@5.3.1 added 1404 packages from 775 contributors in 176.666s