20210725のdockerに関する記事は21件です。

DBFluteハンズオン用データベースをDocker composeで起動する

目的 DBFluteハンズオン用データベースの構築を簡単にするため、Docker composeでMySQLを構築する方法をメモしておきます 環境 MacBook Pro 2019年モデル。 CPUはIntel Core i9, OSはMac OS Catalinaです。 M1 MacでもBig SurでもないのでDockerの利用には特に問題ない状態です。 作ったもの docker-compose.yml version: '3.1' services: db: image: mysql:8.0.26 restart: always environment: MYSQL_ALLOW_EMPTY_PASSWORD: "yes" MYSQL_TCP_PORT: 43376 volumes: - ./my.cnf:/etc/mysql/conf.d/my.cnf - ./mysql/data:/var/lib/mysql ports: - 43376:43376 ポイント DBFluteハンズオンに合わせた設定をしています docker-compose.ymlの配置先 DBFluteハンズオンのMySQL配置先は dbflute-hands-on/localdb/mysql 直下にしました。 Docker composeの慣例的にはプロジェクトルート直下が多い気がします。 MySQLのポートを43376に変更 MYSQL_TCP_PORT: 43376 と ports: - 43376:43376 の部分 共通化のため実際は .env に設定したほうがいいでしょう。今回はハードコードしています ハンズオン用のmy.cnfを読み込む MySQLのDockerイメージの公式を参考に指定しています データフォルダを指定 data フォルダを作成して localdb/mysql/data を指定 rootユーザのパスワードはいったんなしで MYSQL_ALLOW_EMPTY_PASSWORD: "yes" パスワードは必須の方が良いのでしょうが、初期構築上なしにしています 参考 https://hub.docker.com/_/mysql https://dev.mysql.com/doc/refman/8.0/en/setting-environment-variables.html
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【Docker】docker-compose.yml以外のファイルを利用してコンテナ環境を作成する

概要 docker-composeを利用する際には、基本的にdocker-compose.ymlという名前のファイルを作成し、利用することが一般的。 ただ、複数のdocker-compose.ymlを利用するなど、場合によってはdocker-compose.yml名前以外のファイルを利用したい場合が存在する。 今回は別名で作成したyamlを利用してdocker-composeを利用する方法を記載する 別名のyamlファイルを作成した場合 $ docker-compose -f [別名のyamlファイル][オプション] 今回は例として、sample.yaml という名前のファイルを作成したとする。 内容はdocker-composeと同じで以下の通り、 sample.yaml version: "2" services: svelte: image: node:lts-alpine tty: true ports: - 5000:5000 entrypoint: > sleep 86400 $ docker-compose -f sample.yaml up -d
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker 保守。docker(131)

あなたもdocker, 私もdocker。docker(130) https://qiita.com/kaizen_nagoya/items/8f2746f10f30b575d0a8 の記事を書いていて、 資料集 [あなたもdocker私もdocker]。docker(0) https://qiita.com/kaizen_nagoya/items/45699eefd62677f69c1d と なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)。docker(18) https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2 を確認しながら、 docker hubの登録が100を超え、保守作業をはじめました。docker(122) https://qiita.com/kaizen_nagoya/items/3dcb6dab32ed25f66cd8 の一覧とQiita記事の対応を取ろうとした。 r-masterがどの記事と関係あるかわからなくなっていた。 $ docker run -it kaizenjapan/r-master /bin/bash 一つのコンポーネントが1.3Gくらいだった。HDDが不足する。 # ls 9781787287471 etc media sbin ML_for_Hackers home mnt srv Mastering-Machine-Learning-with-R-Second-Edition index.html opt sys bin index.html.1 proc tmp boot lib root usr dev lib64 run var # cd Mastering-Machine-Learning-with-R-Second-Edition/ # ls AppendixA Chapter04 Chapter07 Chapter10 Chapter13 data-master Chapter02 Chapter05 Chapter08 Chapter11 LICENCE Chapter03 Chapter06 Chapter09 Chapter12 README.md # cd .. # cd ML_for_Hackers/ # ls 01-Introduction 05-Regression 09-MDS README.md 02-Exploration 06-Regularization 10-Recommendations fast_check.R 03-Classification 07-Optimization 11-SNA package_installer.R 04-Ranking 08-PCA 12-Model_Comparison slides まだ確認が取れていない。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker 保守。docker(135)

あなたもdocker, 私もdocker。docker(130) https://qiita.com/kaizen_nagoya/items/8f2746f10f30b575d0a8 の記事を書いていて、 資料集 [あなたもdocker私もdocker]。docker(0) https://qiita.com/kaizen_nagoya/items/45699eefd62677f69c1d と なぜdockerで機械学習するか 書籍・ソース一覧作成中 (目標100)。docker(18) https://qiita.com/kaizen_nagoya/items/ddd12477544bf5ba85e2 を確認しながら、 docker hubの登録が100を超え、保守作業をはじめました。docker(122) https://qiita.com/kaizen_nagoya/items/3dcb6dab32ed25f66cd8 の一覧とQiita記事の対応を取ろうとした。 r-masterがどの記事と関係あるかわからなくなっていた。 $ docker run -it kaizenjapan/r-master /bin/bash 一つのコンポーネントが1.3Gくらいだった。HDDが不足する。 # ls 9781787287471 etc media sbin ML_for_Hackers home mnt srv Mastering-Machine-Learning-with-R-Second-Edition index.html opt sys bin index.html.1 proc tmp boot lib root usr dev lib64 run var # cd Mastering-Machine-Learning-with-R-Second-Edition/ # ls AppendixA Chapter04 Chapter07 Chapter10 Chapter13 data-master Chapter02 Chapter05 Chapter08 Chapter11 LICENCE Chapter03 Chapter06 Chapter09 Chapter12 README.md # cd .. # cd ML_for_Hackers/ # ls 01-Introduction 05-Regression 09-MDS README.md 02-Exploration 06-Regularization 10-Recommendations fast_check.R 03-Classification 07-Optimization 11-SNA package_installer.R 04-Ranking 08-PCA 12-Model_Comparison slides まだ確認が取れていない。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[03] docker-composeを活用して即座にJenkinsを立てて使ってみる ... WindowsPC を Slave として登録する

留意事項 本手順を実施する場合は、次のように読み替えること. ・アカウント名の「robozushi10」を各ユーザのアカウントにする ・ホストIP「192.168.10.115」を各ユーザの IP やホスト名にする   概要 前回 からの発展で、次のように別途 Windows 上に Slave を立ち上げる場合 の手順である. 前回までと同じ要領で Windows PC を Slave として登録させることができて、さらに Windows 環境でのデプロイもできるようになるので便利である. // 私の環境では、Slave である Windows PC に対して 5時間以上連続したテストを実施させている 役割 ホスト側ポート コンテナ側ポート 補足 Jenkins Master 43080 43080 Jenkins Slave(1) - - Docker on Docker 可能である Jenkins Slave(2) - - Docker on Docker 可能である Jenkins Slave(3) - - Docker on Docker 可能である Jenkins Slave(4) - - Windows PC上に配置する     手順 1. Slave 用のホームディレクトリを作成する Windows PC での操作である. 1. PowerShell ウインドウを開く 「Windowsキー + R」→「powershell」と入力する 2. ディレクトリを作成する new-item -type Directory C:\JenkinsAgent     2. Jenkins Master 側で Windows PC を Slave として登録する Jenkins Master の WEB-UI での操作である. 登録手順は前回までと同じ要領であり、ここでは次のように入力した.   3. Windows PC から Jenkins Master に JNLP 接続する 1. 事前に Windows PC に対して Java をインストールしておくこと 次の要領でインストールをすれば良い. 1. OpenJDK 15.0.1 の Zip ファイルを Oracle のページから Download してくる.   https://download.java.net/java/GA/jdk15.0.1/51f4f36ad4ef43e39d0dfdbaf6549e32/9/GPL/openjdk-15.0.1_windows-x64_bin.zip 2. 上記 1 で入手した Zip ファイルを展開(unzip)する 3. 展開(unzip) したデータを、ローカルのディスク (例: C:\OpenJDK-15.0.1\) に配置する 4. システム環境変数 JAVA_HOME に「上記 3 で配置したパス」を記す 5. システム環境変数 Path に「上記 3 で配置したパス + /bin」を記す 関連記事: Windows10用 OpenJDK のインストーラを作ろう   2. Slave を稼働させる > java -jar agent.jar -jnlpUrl http://192.168.10.115:43080/computer/WindowsAgent/jenkins-agent.jnlp -workDir "C:\JenkinsAgent" Windows PC で実施した CI/CD の一例については、下記を参照すること. [シリーズ] PowerShell実践例   以上     参考サイトおよび書籍 URL https://www.slideshare.net/miyajan/jenkins-61133952 [改訂第3版]Jenkins実践入門
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

ASP.NET Core 5.0 MVC + SQLiteで作ったアプリをDocker上で動かしてみた!

はじめに Dockerの勉強として、以前ASP.NET Coreで自作したアプリをDocker上で動かしてみました。 動作環境 Windows10 Pro .NET Core SDK 5.0.205 Docker Version 19.03.12 Visual Studio 2019 C:\Work>ver Microsoft Windows [Version 10.0.19042.1110] C:\Work>dotnet --version 5.0.205 C:\Work>docker --version Docker version 19.03.12, build 48a66213fe Dockerfileの作成 続いてDockerfileを作成します。 Visual Studioを利用している方はプロジェクトを右クリック > 追加 > Dockerサポート > Linuxを選択するとテンプレートのDockerfileができますので利用すると良いかもしれません。 僕の場合はプロジェクトを分けているため、一部ファイルの内容を変更しています。 Dockerfile FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base WORKDIR /app EXPOSE 80 EXPOSE 443 #ポート5000を利用するので追加します EXPOSE 5000 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build WORKDIR /src #プロジェクトを分けており、一つ上の階層からDockerfileをビルドするのでパスをテンプレートから変更しています COPY ["TestMaker/TestMaker.csproj", "TestMaker/"] COPY ["DDD.Domain/DDD.Domain.csproj", "DDD.Domain/"] RUN dotnet restore "TestMaker/TestMaker.csproj" COPY . . WORKDIR "/src/TestMaker" RUN dotnet build "TestMaker.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "TestMaker.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "TestMaker.dll"] Dockerfileをビルドする docker build -t testmaker -f "TestMaker/Dockerfile" . ※Dockerfileの一つ上の階層からビルドしました。 以下のようにイメージが作られていることを確認します。 C:\Work\TestMakerProject\TestMaker>docker images REPOSITORY TAG IMAGE ID CREATED SIZE testmaker latest addaa2f7e45d 16 minutes ago 263MB <none> <none> a353b688a51d 16 minutes ago 1.3GB mcr.microsoft.com/dotnet/sdk 5.0 fa98367f9017 3 days ago 631MB mcr.microsoft.com/dotnet/aspnet 5.0 44ffd671d35d 3 days ago 205MB 対象のイメージからコンテナを作成します。 ポートは8080としていますが、こちらは任意の値でいいかと思います。 C:\Work\TestMakerProject\TestMaker>docker run --rm -p 8080:5000 testmaker testmaker_onDocker warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60] Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed. warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35] No XML encryptor configured. Key {7ab3713d-e0fb-40e3-9902-73b9ca437986} may be persisted to storage in unencrypted form. info: Microsoft.Hosting.Lifetime[0] Now listening on: http://[::]:5000 info: Microsoft.Hosting.Lifetime[0] Application started. Press Ctrl+C to shut down. info: Microsoft.Hosting.Lifetime[0] Hosting environment: Production info: Microsoft.Hosting.Lifetime[0] Content root path: /app 完成 http://localhost:8080 へアクセスすると無事に以下のようにアプリが正しく立ち上がることが確認できました! 終わりに 今回はDockerの勉強として以前作成したアプリをコンテナ化してみました! Linux上でも動くことを簡単に確認できるのでDockerは便利ですね。 アプリのソースコードは以下にあるのでもし参考になりそうでしたらどうぞ~ https://github.com/Oooooomin2/TestMaker おまけ もしDockerfileが無事にビルドできたけど正常にアプリが立ち上がらない場合は以下の処理が抜けている可能性があります。 https://docs.microsoft.com/ja-jp/aspnet/core/fundamentals/host/web-host?view=aspnetcore-5.0#server-urls 2021/07/26追記 こちらの「おまけ」についてですが、別途ご教示をいただいた「おまけ2」の方より良い方法ですのでそちらをご確認くださいませ~! 今回はProgram.csに以下のコードを追記しています。 program.cs public static IHostBuilder CreateHostBuilder(string[] args) => Host.CreateDefaultBuilder(args) .ConfigureWebHostDefaults(webBuilder => { webBuilder.UseUrls("http://*:5000"); // <- 新たに追加 webBuilder.UseStartup<Startup>(); }); おまけ2(2021/07/26追記) 「おまけ」として書いた上記の内容について、お客様先(現在常駐している会社)の上司にもっと良い方法あるよ~!と2点教えてもらったので忘れないように追記します! その1:ASPNETCORE_URLSを環境変数として渡す 上記の「おまけ」ではソースコード上にサーバのURLを記載していましたが、DockerfileにASPNETCore_URLを環境変数として渡す内容を追記することでアクセスが可能になります。上記で記載していたDockerfileの下から2行目に「ENV ASPNETCORE_URLS http://*:5000」を追記します。 Dockerfile FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base WORKDIR /app EXPOSE 80 EXPOSE 443 EXPOSE 5000 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build WORKDIR /src COPY ["TestMaker/TestMaker.csproj", "TestMaker/"] COPY ["DDD.Domain/DDD.Domain.csproj", "DDD.Domain/"] RUN dotnet restore "TestMaker/TestMaker.csproj" COPY . . WORKDIR "/src/TestMaker" RUN dotnet build "TestMaker.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "TestMaker.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . # ASPNETCORE_URLSを環境変数として渡す ENV ASPNETCORE_URLS http://*:5000 ENTRYPOINT ["dotnet", "TestMaker.dll"] これでDockerfileをビルドして元の手順通りに進めてもブラウザからアクセスできるようになるかと思います。 その2:ASPNETCORE_ENVIRONMENTがProductionの場合はポート80でバインドされるので直接ポート80を指定する 環境変数ASPNETCORE_ENVIRONMENTはデフォルトでは"Production"となります。 https://docs.microsoft.com/en-us/aspnet/core/fundamentals/environments?view=aspnetcore-5.0#environments その際はポート80でバインドされるため、docker runの際に-pで5000:80を指定する。 C:\Work\TestMakerProject\TestMaker>docker run --rm -p 5000:80 testmaker testmaker_onDocker ※この場合は上記「その1:ASPNETCORE_URLSを環境変数として渡す」で記載したASPNETCORE_URLSはDockerfileに記載していません。 どちらもソースコードをいじらずに実現できるのでこちらの方が便利です!! 色々とご教示いただけるので本当に感謝です!(^^)!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[02] docker-composeを活用して即座にJenkinsを立てて使ってみる ... 1マスタ、3スレーブ

留意事項 本手順を実施する場合は、次のように読み替えること. ・アカウント名の「robozushi10」を各ユーザのアカウントにする ・ホストIP「192.168.10.115」を各ユーザの IP やホスト名にする   概要 前回 からの発展で、次の構成の Jenkins on Docker のセットアップ手順である. // 私の場合は Slave が 3つあれば間に合うことが多い 一度構築すれば、他のホスト上でも一部書き換えるだけ※ でセットアップができる. (※ ホストIP の書き換えのみ) 役割 ホスト側ポート コンテナ側ポート 補足 Jenkins Master 43080 43080 Jenkins Slave(1) - - Docker on Docker 可能である Jenkins Slave(2) - - Docker on Docker 可能である Jenkins Slave(3) - - Docker on Docker 可能である     手順 1. 前回起動させたコンテナおよびイメージを一掃する $ docker-compose down --rmi all --volumes --remove-orphans このとき、ホスト上から見たデータは次のようになっている . |-- PV | |-- jenkinsmaster | | `-- jenkins_home | | |-- 以下略 | `-- jenkinsslave1 | |-- agent | |-- agent.jar | |-- remoting | `-- secret-file `-- docker-compose.yml   2. 素の Jenkins on Docker を起動させる 1. docker-compose.yml を変更する 前回 のコードに対して、次の変更を加える. --- a/docker-compose.yml +++ b/docker-compose.yml @@ -20,3 +20,21 @@ services: - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker:ro command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave1-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"' + jenkinsslave2: + container_name: myjenkinsslave2 + user: root + image: jenkinsci/slave + volumes: + - ./PV/jenkinsslave2:/home/jenkins + - /var/run/docker.sock:/var/run/docker.sock + - /usr/bin/docker:/usr/bin/docker:ro + command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave2-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"' + jenkinsslave3: + container_name: myjenkinsslave3 + user: root + image: jenkinsci/slave + volumes: + - ./PV/jenkinsslave3:/home/jenkins + - /var/run/docker.sock:/var/run/docker.sock + - /usr/bin/docker:/usr/bin/docker:ro + command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave3-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"'   2. docker-compose up -d を実行する $ docker-compose ps Name Command State Ports ----------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up myjenkinsslave2 /bin/bash -c java -jar /ho ... Exit 1 myjenkinsslave3 /bin/bash -c java -jar /ho ... Exit 1     2. WEB-UI で localhost:43080 にログインして「slave2-local」を追加登録する 1. 「slave2-local」を登録する 下記 URL にアクセスして、下図の要領で登録する. http://localhost:43080/computer/new   2. パラメータを設定する   3. 「slave3-local」のパラメータを控えておく   4. ホストで次を実行する 上記で表示されたシークレットを、./PV/jenkinsslave2/secret-file として書き出す. $ cat <<'EOL' | sudo tee PV/jenkinsslave2/secret-file ca5900b9f1a887405b35d7c52410652326ceb896d4c5b0033c269c43940ba018 EOL   5. Slave上に agent.jar を配置する ホストで次の操作をして ./PV/jenkinsslave2/agent.jar として配置する. $ sudo wget http://localhost:43080/jnlpJars/agent.jar -O PV/jenkinsslave2/agent.jar     3. WEB-UI で localhost:43080 にログインして「slave3-local」を追加登録する 上記 2 と同じ要領で「slave3-local」を登録する.     4. コンテナ群を再起動する $ docker-compose restart Restarting myjenkinsmaster ... done Restarting myjenkinsslave1 ... done Restarting myjenkinsslave3 ... done Restarting myjenkinsslave2 ... done 次のように表示されていれば OK. $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up myjenkinsslave2 /bin/bash -c java -jar /ho ... Up myjenkinsslave3 /bin/bash -c java -jar /ho ... Up     5. Slave 2台が起動していることを確認する   以上     参考サイトおよび書籍 URL https://www.slideshare.net/miyajan/jenkins-61133952 https://qiita.com/sugiyasu-qr/items/85a1bedb6458d4573407 [改訂第3版]Jenkins実践入門
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[02] docker-composeを活用して即座にJenkinsを立てて使ってみる(2) ... 1マスタ、3スレーブ

留意事項 本手順を実施する場合は、次のように読み替えること. ・アカウント名の「robozushi10」を各ユーザのアカウントにする ・ホストIP「192.168.10.115」を各ユーザの IP やホスト名にする   概要 前回 からの発展で、次の構成の Jenkins on Docker のセットアップ手順である. // 私の場合は Slave が 3つあれば間に合うことが多い 一度構築すれば、他のホスト上でも一部書き換えるだけ※ でセットアップができる. (※ ホストIP の書き換えのみ) 役割 ホスト側ポート コンテナ側ポート 補足 Jenkins Master 43080 43080 Jenkins Slave(1) - - Docker on Docker 可能である Jenkins Slave(2) - - Docker on Docker 可能である Jenkins Slave(3) - - Docker on Docker 可能である     手順 1. 前回起動させたコンテナおよびイメージを一掃する $ docker-compose down --rmi all --volumes --remove-orphans このとき、ホスト上から見たデータは次のようになっている . |-- PV | |-- jenkinsmaster | | `-- jenkins_home | | |-- 以下略 | `-- jenkinsslave1 | |-- agent | |-- agent.jar | |-- remoting | `-- secret-file `-- docker-compose.yml   2. 素の Jenkins on Docker を起動させる 1. docker-compose.yml を変更する 前回 のコードに対して、次の変更を加える. --- a/docker-compose.yml +++ b/docker-compose.yml @@ -20,3 +20,21 @@ services: - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker:ro command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave1-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"' + jenkinsslave2: + container_name: myjenkinsslave2 + user: root + image: jenkinsci/slave + volumes: + - ./PV/jenkinsslave2:/home/jenkins + - /var/run/docker.sock:/var/run/docker.sock + - /usr/bin/docker:/usr/bin/docker:ro + command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave2-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"' + jenkinsslave3: + container_name: myjenkinsslave3 + user: root + image: jenkinsci/slave + volumes: + - ./PV/jenkinsslave3:/home/jenkins + - /var/run/docker.sock:/var/run/docker.sock + - /usr/bin/docker:/usr/bin/docker:ro + command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave3-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"'   2. docker-compose up -d を実行する $ docker-compose ps Name Command State Ports ----------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up myjenkinsslave2 /bin/bash -c java -jar /ho ... Exit 1 myjenkinsslave3 /bin/bash -c java -jar /ho ... Exit 1     2. WEB-UI で localhost:43080 にログインして「slave2-local」を追加登録する 1. 「slave2-local」を登録する 下記 URL にアクセスして、下図の要領で登録する. http://localhost:43080/computer/new   2. パラメータを設定する   3. 「slave3-local」のパラメータを控えておく   4. ホストで次を実行する 上記で表示されたシークレットを、./PV/jenkinsslave2/secret-file として書き出す. $ cat <<'EOL' | sudo tee PV/jenkinsslave2/secret-file ca5900b9f1a887405b35d7c52410652326ceb896d4c5b0033c269c43940ba018 EOL   5. Slave上に agent.jar を配置する ホストで次の操作をして ./PV/jenkinsslave2/agent.jar として配置する. $ sudo wget http://localhost:43080/jnlpJars/agent.jar -O PV/jenkinsslave2/agent.jar     3. WEB-UI で localhost:43080 にログインして「slave3-local」を追加登録する 上記 2 と同じ要領で「slave3-local」を登録する.     4. コンテナ群を再起動する $ docker-compose restart Restarting myjenkinsmaster ... done Restarting myjenkinsslave1 ... done Restarting myjenkinsslave3 ... done Restarting myjenkinsslave2 ... done 次のように表示されていれば OK. $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up myjenkinsslave2 /bin/bash -c java -jar /ho ... Up myjenkinsslave3 /bin/bash -c java -jar /ho ... Up     5. Slave 2台が起動していることを確認する   以上     参考サイトおよび書籍 URL https://www.slideshare.net/miyajan/jenkins-61133952 https://qiita.com/sugiyasu-qr/items/85a1bedb6458d4573407 [改訂第3版]Jenkins実践入門
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[01] docker-composeを活用して即座にJenkinsを立てて使ってみる ... 1マスタ、1スレーブ構成

留意事項 本手順を実施する場合は、次のように読み替えること. ・アカウント名の「robozushi10」を各ユーザのアカウントにする ・ホストIP「192.168.10.115」を各ユーザの IP やホスト名にする   概要 次の構成の Jenkins on Docker のセットアップ手順である. 一度構築すれば、他のホスト上でも一部書き換えるだけ※ でセットアップができる. (※ ホストIP の書き換えのみ) 役割 ホスト側ポート コンテナ側ポート 補足 Jenkins Master 43080 43080 Jenkins Slave(1) - - Docker on Docker 可能である     手順 1. 素の Jenkins on Docker を起動させる 1. docker-compose.yml を作成する. version: "3" services: jenkinsmaster: container_name: myjenkinsmaster user: root image: jenkins/jenkins:latest environment: - JENKINS_OPTS="--httpPort=43080" ports: - 43080:43080 - 43000:43000 volumes: - ./PV/jenkinsmaster/jenkins_home:/var/jenkins_home jenkinsslave1: container_name: myjenkinsslave1 user: root image: jenkinsci/slave volumes: - ./PV/jenkinsslave1:/home/jenkins - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker:ro command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave1-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"'   2. docker-compose up -d を実行する $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up     2. WEB-UI で localhost:43080 にログインする 1. 初期ログインパスワードを入手する $ docker-compose exec jenkinsmaster bash -c 'cat /var/jenkins_home/secrets/initialAdminPassword' 87e4804b07124cbf934d3c9346378de2   2. 推奨プラグインをインストールする 300MB ほどディスクを喰うが仕方ない.   3. 管理者アカウントを作成する 「Create First Admin User」で管理者アカウントを作る. 今回は次のアカウントを作成した. アカウント ... root パスワード ... rootroot     3. 開発用アカウントを作成する 1. アカウント作成 http://localhost:43080/securityRealm/addUser にアクセスして開発用アカウントを作成する. 今回は次のアカウントを作成した. アカウント ... robozushi10 パスワード ... robozushi10   2. APIキーを作成する 下記にアクセスして「APIトークン」を「生成」してから「保存」する. http://localhost:43080/user/robozushi10/configure 「APIトークン」生成したら控えておくこと. 115055bf04f7f0508abacc987625165188     4. Jenkins Master の設定をする 1. Jenkins URL を設定する 「Jenkinsの管理」→「システムの設定」より、 ホストの IPアドレス「192.168.10.115」を設定する.     5. 新規ノード「slave1-local」を立ち上げる 1. 「slave1-local」を作成する http://localhost:43080/computer/new にアクセスして、ノード名で「slave1-local」でノードを作成する. このとき次のようにする. 項目 値 補足 リモートFSルート 「/home/jenkins」と入力する docker-compose.yml での volumes と合わせている ラベル 「slave1」と入力する 用途 「このマシンを特定ジョブ専用にする」を選択する 起動方法 「Launch agent by connecting it to the master」を選択する   2. 「slave1-local」のパラメータを控えておく 作成したノード「slave1-local」の状態確認ページ(下記) を開いて起動パラメータを控える. http://localhost:43080/computer/slave1-local/ 次のような情報が表示されているので控えておく. echo 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b > secret-file java -jar agent.jar -jnlpUrl http://localhost:43080/computer/slave1-local/jenkins-agent.jnlp -secret @secret-file -workDir "/home/jenkins"   3. Agents のポート番号を 43080 へと変更する 下記「グローバルセキュリティの設定」より、 「Agents」のポート番号を「50000」から「43000」へと変更する. http://localhost:43080/configureSecurity/   4. ホストで次を実行する 上記 2 で表示されたシークレットを、./PV/jenkinsslave1/secret-file として書き出す. $ cat <<'EOL' | sudo tee PV/jenkinsslave1/secret-file 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b EOL     5. Slave上に agent.jar を配置する ホストで次の操作をして ./PV/jenkinsslave1/agent.jar として配置する. $ sudo wget http://localhost:43080/jnlpJars/agent.jar -O PV/jenkinsslave1/agent.jar     6. Jenkins を再起動させる $ sudo docker-compose restart   以上.     デバッグ Master と Slave が繋がらない場合 ホストで次のように実行して接続可能かチェックをすれば良い. $ java -jar PV/jenkinsslave1/agent.jar -jnlpUrl http://localhost:43080/computer/slave1-local/jenkins-agent.jnlp -secret 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b   参考サイト URL https://www.slideshare.net/miyajan/jenkins-61133952 https://qiita.com/sugiyasu-qr/items/85a1bedb6458d4573407 [改訂第3版]Jenkins実践入門
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[01] Jenkins on Docker のセットアップ ... 1マスタ、1スレーブ

留意事項 本手順を実施する場合は、次のように読み替えること. ・アカウント名の「robozushi10」を各ユーザのアカウントにする ・ホストIP「192.168.10.115」を各ユーザの IP やホスト名にする   概要 次の構成の Jenkins on Docker のセットアップ手順である. 一度構築すれば、他のホスト上でも一部書き換えるだけ※ でセットアップができる. (※ ホストIP の書き換えのみ) 役割 ホスト側ポート コンテナ側ポート 補足 Jenkins Master 43080 43080 Jenkins Slave(1) - - Docker on Docker 可能である     手順 1. 素の Jenkins on Docker を起動させる 1. docker-compose.yml を作成する. version: "3" services: jenkinsmaster: container_name: myjenkinsmaster user: root image: jenkins/jenkins:latest environment: - JENKINS_OPTS="--httpPort=43080" ports: - 43080:43080 - 43000:43000 volumes: - ./PV/jenkinsmaster/jenkins_home:/var/jenkins_home jenkinsslave1: container_name: myjenkinsslave1 user: root image: jenkinsci/slave volumes: - ./PV/jenkinsslave1:/home/jenkins - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker:ro command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave1-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"'   2. docker-compose up -d を実行する $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up     2. WEB-UI で localhost:43080 にログインする 1. 初期ログインパスワードを入手する $ docker-compose exec jenkinsmaster bash -c 'cat /var/jenkins_home/secrets/initialAdminPassword' 87e4804b07124cbf934d3c9346378de2   2. 推奨プラグインをインストールする 300MB ほどディスクを喰うが仕方ない.   3. 管理者アカウントを作成する 「Create First Admin User」で管理者アカウントを作る. 今回は次のアカウントを作成した. アカウント ... root パスワード ... rootroot     3. 開発用アカウントを作成する 1. アカウント作成 http://localhost:43080/securityRealm/addUser にアクセスして開発用アカウントを作成する. 今回は次のアカウントを作成した. アカウント ... robozushi10 パスワード ... robozushi10   2. APIキーを作成する 下記にアクセスして「APIトークン」を「生成」してから「保存」する. http://localhost:43080/user/robozushi10/configure 「APIトークン」生成したら控えておくこと. 115055bf04f7f0508abacc987625165188     4. Jenkins Master の設定をする 1. Jenkins URL を設定する 「Jenkinsの管理」→「システムの設定」より、 ホストの IPアドレス「192.168.10.115」を設定する.     5. 新規ノード「slave1-local」を立ち上げる 1. 「slave1-local」を作成する http://localhost:43080/computer/new にアクセスして、ノード名で「slave1-local」でノードを作成する. このとき次のようにする. 項目 値 補足 リモートFSルート 「/home/jenkins」と入力する docker-compose.yml での volumes と合わせている ラベル 「slave1」と入力する 用途 「このマシンを特定ジョブ専用にする」を選択する 起動方法 「Launch agent by connecting it to the master」を選択する   2. 「slave1-local」のパラメータを控えておく 作成したノード「slave1-local」の状態確認ページ(下記) を開いて起動パラメータを控える. http://localhost:43080/computer/slave1-local/ 次のような情報が表示されているので控えておく. echo 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b > secret-file java -jar agent.jar -jnlpUrl http://localhost:43080/computer/slave1-local/jenkins-agent.jnlp -secret @secret-file -workDir "/home/jenkins"   3. Agents のポート番号を 43080 へと変更する 下記「グローバルセキュリティの設定」より、 「Agents」のポート番号を「50000」から「43000」へと変更する. http://localhost:43080/configureSecurity/   4. ホストで次を実行する 上記 2 で表示されたシークレットを、./PV/jenkinsslave1/secret-file として書き出す. $ cat <<'EOL' | sudo tee PV/jenkinsslave1/secret-file 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b EOL     5. Slave上に agent.jar を配置する ホストで次の操作をして ./PV/jenkinsslave1/agent.jar として配置する. $ sudo wget http://localhost:43080/jnlpJars/agent.jar -O PV/jenkinsslave1/agent.jar     6. Jenkins を再起動させる $ sudo docker-compose restart   以上.     デバッグ Master と Slave が繋がらない場合 ホストで次のように実行して接続可能かチェックをすれば良い. $ java -jar PV/jenkinsslave1/agent.jar -jnlpUrl http://localhost:43080/computer/slave1-local/jenkins-agent.jnlp -secret 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b   参考サイト URL https://www.slideshare.net/miyajan/jenkins-61133952
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

[01] docker-composeを活用して即座にJenkinsを立てて使ってみる(1) ... 1マスタ、1スレーブ構成

留意事項 本手順を実施する場合は、次のように読み替えること. ・アカウント名の「robozushi10」を各ユーザのアカウントにする ・ホストIP「192.168.10.115」を各ユーザの IP やホスト名にする   概要 次の構成の Jenkins on Docker のセットアップ手順である. 一度構築すれば、他のホスト上でも一部書き換えるだけ※ でセットアップができる. (※ ホストIP の書き換えのみ) 役割 ホスト側ポート コンテナ側ポート 補足 Jenkins Master 43080 43080 Jenkins Slave(1) - - Docker on Docker 可能である     手順 1. 素の Jenkins on Docker を起動させる 1. docker-compose.yml を作成する. version: "3" services: jenkinsmaster: container_name: myjenkinsmaster user: root image: jenkins/jenkins:latest environment: - JENKINS_OPTS="--httpPort=43080" ports: - 43080:43080 - 43000:43000 volumes: - ./PV/jenkinsmaster/jenkins_home:/var/jenkins_home jenkinsslave1: container_name: myjenkinsslave1 user: root image: jenkinsci/slave volumes: - ./PV/jenkinsslave1:/home/jenkins - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker:ro command: /bin/bash -c 'java -jar /home/jenkins/agent.jar -jnlpUrl http://jenkinsmaster:43080/computer/slave1-local/jenkins-agent.jnlp -secret @/home/jenkins/secret-file -workDir "/home/jenkins"'   2. docker-compose up -d を実行する $ docker-compose ps Name Command State Ports ---------------------------------------------------------------------------------------------------------------------------------- myjenkinsmaster /sbin/tini -- /usr/local/b ... Up 0.0.0.0:43000->43000/tcp, 0.0.0.0:43080->43080/tcp, 50000/tcp, 8080/tcp myjenkinsslave1 /bin/bash -c java -jar /ho ... Up     2. WEB-UI で localhost:43080 にログインする 1. 初期ログインパスワードを入手する $ docker-compose exec jenkinsmaster bash -c 'cat /var/jenkins_home/secrets/initialAdminPassword' 87e4804b07124cbf934d3c9346378de2   2. 推奨プラグインをインストールする 300MB ほどディスクを喰うが仕方ない.   3. 管理者アカウントを作成する 「Create First Admin User」で管理者アカウントを作る. 今回は次のアカウントを作成した. アカウント ... root パスワード ... rootroot     3. 開発用アカウントを作成する 1. アカウント作成 http://localhost:43080/securityRealm/addUser にアクセスして開発用アカウントを作成する. 今回は次のアカウントを作成した. アカウント ... robozushi10 パスワード ... robozushi10   2. APIキーを作成する 下記にアクセスして「APIトークン」を「生成」してから「保存」する. http://localhost:43080/user/robozushi10/configure 「APIトークン」生成したら控えておくこと. 115055bf04f7f0508abacc987625165188     4. Jenkins Master の設定をする 1. Jenkins URL を設定する 「Jenkinsの管理」→「システムの設定」より、 ホストの IPアドレス「192.168.10.115」を設定する.     5. 新規ノード「slave1-local」を立ち上げる 1. 「slave1-local」を作成する http://localhost:43080/computer/new にアクセスして、ノード名で「slave1-local」でノードを作成する. このとき次のようにする. 項目 値 補足 リモートFSルート 「/home/jenkins」と入力する docker-compose.yml での volumes と合わせている ラベル 「slave1」と入力する 用途 「このマシンを特定ジョブ専用にする」を選択する 起動方法 「Launch agent by connecting it to the master」を選択する   2. 「slave1-local」のパラメータを控えておく 作成したノード「slave1-local」の状態確認ページ(下記) を開いて起動パラメータを控える. http://localhost:43080/computer/slave1-local/ 次のような情報が表示されているので控えておく. echo 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b > secret-file java -jar agent.jar -jnlpUrl http://localhost:43080/computer/slave1-local/jenkins-agent.jnlp -secret @secret-file -workDir "/home/jenkins"   3. Agents のポート番号を 43080 へと変更する 下記「グローバルセキュリティの設定」より、 「Agents」のポート番号を「50000」から「43000」へと変更する. http://localhost:43080/configureSecurity/   4. ホストで次を実行する 上記 2 で表示されたシークレットを、./PV/jenkinsslave1/secret-file として書き出す. $ cat <<'EOL' | sudo tee PV/jenkinsslave1/secret-file 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b EOL     5. Slave上に agent.jar を配置する ホストで次の操作をして ./PV/jenkinsslave1/agent.jar として配置する. $ sudo wget http://localhost:43080/jnlpJars/agent.jar -O PV/jenkinsslave1/agent.jar     6. Jenkins を再起動させる $ sudo docker-compose restart   以上.     デバッグ Master と Slave が繋がらない場合 ホストで次のように実行して接続可能かチェックをすれば良い. $ java -jar PV/jenkinsslave1/agent.jar -jnlpUrl http://localhost:43080/computer/slave1-local/jenkins-agent.jnlp -secret 93d7204e5036a10274696a371cb5531747056ec637d50b1aa7691217e8a5ee9b   参考サイト URL https://www.slideshare.net/miyajan/jenkins-61133952 https://qiita.com/sugiyasu-qr/items/85a1bedb6458d4573407 [改訂第3版]Jenkins実践入門
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Mac with intel chip Mac with Apple chip

intel chipとApple chipどちらをインストールすればよいのか ↓確認 ↓確認   intelのコアなら、Mac with intel chip。AppleならMac with Aplle chip *chip・・・シリコンなどの半導体でできた数mmから数cm角の基板の上に、多数の微細な電子素子や配線を実装した装置を「ICチップ」(IC chip)「マイクロチップ」(microchip)などと呼び、これを略してチップということが多い。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerコンテナ内でホストと同じユーザで作業(sudoコマンド有り)

目的 ホストのUID/GIDで作業可能なsudo付きDockerコンテナをDockerfileを作成せず、かつ出来るだけ制約の少ない方法で立ち上げる。 背景 Dockerコンテナを開発環境として使っていると、デフォルトがrootユーザなせいで、ファイルのownerの問題にぶち当たる。 よくあるパターンが、ディレクトリをマウントして作成したファイルのownerがrootになってて、がホスト側から編集出来ない、とかいうケース。 Dockerコンテナを開発環境に使ってると、よくこのパターンにハマり、ownerを変更するためだけにコンテナを起動したりすることも...。 回避方法として-u $(id -u):$(id -g)のオプションを付ける方法あるが、これだけではホスト側のユーザIDと一致しなかったり、sudoが使えなかったりと困ることも多い。 じゃあ、sudoインストールしたりuseraddしたりするDockerfileを作るというのもあるが、いちいちpullしてきたイメージに対してそれをやるのも面倒。 というわけで、できるだけ簡単にホストユーザのsudo付きDockerコンテナを立ち上げるコマンドの紹介。 方法 UbuntuとCentOSで若干違うので分けて記載。 Ubuntu コンテナ名は適当にtest-user-with-sudoとでもしときます。 CNAME=test-user-with-sudo まずは、コンテナ起動。 ubuntu docker run -it --name ${CNAME} \ -u $(id -u):$(id -g) \ -v /etc/group:/etc/group:ro -v /etc/passwd:/etc/passwd:ro \ -v ${HOME}/src:${HOME}/src -w ${HOME} \ ubuntu:20.04 bash -u $(id -u):$(id -g) : ユーザ:グループを指定 -v /etc/group:/etc/group:ro -v /etc/passwd:/etc/passwd:ro:ホスト側との整合性(リードオンリー) -v ${HOME}/src:${HOME}/src:お好み。私の場合はソースコードとか大抵ホームディレクトリに置いてるので。 -w ${HOME}:お好み。コンテナ入る度にホームディレクトリに移動するのが面倒なので。 このままだと、 $ sudo apt update bash: sudo: command not found のようにsudoが使えないため、使えるようにする。 コンテナ起動後、一旦C-p C-qで抜ける。 ubuntu docker exec -it -u root ${CNAME} \ bash -c "apt update && apt install sudo -y \ && ( echo $(id -nu):$(id -nu) | /usr/sbin/chpasswd ) \ && ( echo \"$(id -nu) ALL=(ALL:ALL) NOPASSWD: ALL\" | tee /etc/sudoers.d/$(id -nu) )" apt install sudo -y:sudoをインストール echo $(id -nu):$(id -nu) | /usr/sbin/chpasswd:パスワードを設定(パスワードにユーザ名を使用している)。 一見すると/etc/passwdがroなので実行できなそうに見えるが、実際パスワードは/etc/shadowに保存されており、こちらはマウントしていないため問題なく実行できる。 echo \"$(id -nu) ALL=(ALL:ALL) NOPASSWD: ALL\" | tee /etc/sudoers.d/$(id -nu) ):sudoをパスワード無しで実行できるようにする。 パスワード無しはセキュリティ的に...と感じるかもしれないが、上記のコマンドから分かるように、そもそも横から簡単にrootで実行できちゃうため、ここでは気にしない。 今回はあくまで開発環境など性善説的な場面を想定しており、セキュリティ面を気にする場合はrootlessモードを使うのが良さそう。 パスワード無しsudoなので「パスワードの設定」は不要そうだが、パスワード設定をしておかないとsudoコマンドが使えなかったため設定。 動作確認。 # ホスト $ docker attach ${CNAME} ----- # コンテナ内 $ sudo apt update CentOS パスワードの設定方法が若干違うが、基本的に同じ。 CNAME=test-suer-with-sudo docker run -it --name ${CNAME} \ -u $(id -u):$(id -g) \ -v /etc/group:/etc/group:ro -v /etc/passwd:/etc/passwd:ro \ -v ${HOME}/src:${HOME}/src -w ${HOME} \ centos:8 bash # C-p C-q で抜ける docker exec -it -u root ${CNAME} \ bash -c "yum install sudo passwd -y \ && ( echo $(id -nu) | passwd --stdin $(id -nu) ) \ && ( echo \"$(id -nu) ALL=(ALL:ALL) NOPASSWD: ALL\" | tee /etc/sudoers.d/$(id -nu) )" 最後に Dockerコンテナを開発環境として使うと、ツールのインストールやビルド済みのイメージが使えたりしていろいろ便利です。 マシンが自分しかログインしない場合には、${HOME}を丸ごとマウントしてsshの設定などを引き継ぐ、みたいな使い方もできます。ただし、コンテナにアタッチされるとホームディレクトリが丸見えなので、使用の際にはご注意を。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerでリモートデスクトップがubuntuに繋がらなくなった場合の対処法

Docker上でWindowsのリモートデスクトップでubuntuのデスクトップを表示し、終了して、 再起動して再びリモートデスクトップで繋ごうとしたら、繋がらなくなった。 繋がる場合は↓のようになる。 繋がらない場合は↓のようになる。 service xrdp start でスタートさせると、下記のような表示になる。 service xrdp start * Starting Remote Desktop Protocol server It looks like xrdp is allready running, if not delete the xrdp.pid file and try again sesman is already running. if it's not running, try removing /var/run/xrdp/xrdp-sesman.pid ここで、/var/run/xrdp/xrdp-sesman.pid を削除しても繋がらない rm /var/run/xrdp/*  とし、(/var/run/xrdpフォルダ内をすべて削除) service xrdp stop service xrdp start とすると、繋がる。 以上
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerの基本的なネットワークについて

はじめに Dockerの基本的なネットワークの設定について学習. デフォルトでは3種類のネットワークがある。 取り扱ったコマンド docker network docker network ls docker network create docker network connect docker network disconnect docker network inspect bridgeネットワーク デフォルトではここに所属 L2接続 dockerデーモンによるDNS機能が提供されないため名前解決ができない(コンテナ名で通信できない) ユーザ定義ネットワーク bridgeでDNS機能が使える(コンテナ名で通信ができる) hostネットワーク ホストのIPと同じIPがコンテナに適用される(NAPT) ポート番号でコンテナごとに識別している noneネットワーク スタンドアロン(今回詳細な説明は省きます。) ループバックインターフェースしか持たない このネットワークに所属するには他のネットワークに所属してはいけない それぞれのネットワークが接続されている状態は下図の様になる。 bridgeネットワークの接続と疎通確認 bridgeネットワークはコンテナを作成した時にデフォルトで接続されるネットワークで明示的に指定する必要はない。 alpineLinuxコンテナとnginxコンテナを作成。 docker@nw1-vm:~$ docker run -itd --name bridge-alpine1 alpine 24646f5761bcc86e22033c14544e95e8deafe231c6db313e86811046fad283c0 docker@nw1-vm:~$ docker run -itd --name bridge-nginx -p 8080:80 nginx f13da9c76e923960a445847b737a0dfbc3b3655fb2ebba41a0dbd98f0fa29db0 docker@nw1-vm:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f13da9c76e92 nginx "/docker-entrypoint.…" 3 seconds ago Up 2 seconds 0.0.0.0:8080->80/tcp bridge-nginx 24646f5761bc alpine "/bin/sh" 16 seconds ago Up 16 seconds bridge-alpine1 docker@nw1-vm:~$ ネットワーク側の接続確認 docker network inspectコマンドでネットワークの詳細を確認できる 長いので一部抜粋 172.17.0.0/16のネットワークに 172.16.0.2(alpine1),172.168.0.3(nginx)が接続されていることがわかります。 "Name": "bridge", "Id": "af3424acd307e3d96cc99e839670afb5503a859261aac66db6ccbbc7061005b5", "Created": "2021-07-24T22:00:22.322553435Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": null, "Config": [ { "Subnet": "172.17.0.0/16", #ネットワークアドレス "Gateway": "172.17.0.1" #ホストのIP } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "24646f5761bcc86e22033c14544e95e8deafe231c6db313e86811046fad283c0": { "Name": "bridge-alpine1", "EndpointID": "c9bde7f3053b8dd0c43b498e5f34106c98f38b53ea071367c0df37a59aab41b5", "MacAddress": "02:42:ac:11:00:02", "IPv4Address": "172.17.0.2/16", #bridge-alpine1のIP "IPv6Address": "" }, "f13da9c76e923960a445847b737a0dfbc3b3655fb2ebba41a0dbd98f0fa29db0": { "Name": "bridge-nginx", "EndpointID": "9ea7e5ccf04466ac9acfae5754bb00b5a72030204d147e747cacfc4ac2e4bbd0", "MacAddress": "02:42:ac:11:00:03", "IPv4Address": "172.17.0.3/16", #bridge-nginxのIP "IPv6Address": "" } }, gatewayにあるIPアドレスはホストのIPアドレスです。 ip aやifconfigaなどでホストのインターフェースを確認すると同じアドレスがあるかと思います。 ip aの結果 6: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether 02:42:d8:e0:8a:a2 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever inet6 fe80::42:d8ff:fee0:8aa2/64 scope link valid_lft forever preferred_lft forever コンテナ側のネットワーク確認 docker inspectコマンドで表示できるコンテナの詳細で確認できます。 こちらも長いので一部抜粋。出力の最下部に表示されます。 "Networks": { "bridge": { "IPAMConfig": null, "Links": null, "Aliases": null, "NetworkID": "af3424acd307e3d96cc99e839670afb5503a859261aac66db6ccbbc7061005b5", "EndpointID": "c9bde7f3053b8dd0c43b498e5f34106c98f38b53ea071367c0df37a59aab41b5", "Gateway": "172.17.0.1", "IPAddress": "172.17.0.2", "IPPrefixLen": 16, "IPv6Gateway": "", "GlobalIPv6Address": "", "GlobalIPv6PrefixLen": 0, "MacAddress": "02:42:ac:11:00:02", "DriverOpts": null } } 通信確認 この状態でのネットワーク図は以下の通りです。 コンテナ間 bridge-alpine1とbridge-nginx間の通信。L2接続なのでもちろん通信可能です。 docker@nw1-vm:~$ docker exec -it bridge-alpine1 /bin/sh / # ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN qlen 1000 link/sit 0.0.0.0 brd 0.0.0.0 20: eth0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0 valid_lft forever preferred_lft forever / # ping 172.17.0.3 PING 172.17.0.3 (172.17.0.3): 56 data bytes 64 bytes from 172.17.0.3: seq=0 ttl=64 time=0.096 ms 64 bytes from 172.17.0.3: seq=1 ttl=64 time=0.086 ms 64 bytes from 172.17.0.3: seq=2 ttl=64 time=0.086 ms 64 bytes from 172.17.0.3: seq=3 ttl=64 time=0.089 ms 64 bytes from 172.17.0.3: seq=4 ttl=64 time=0.470 ms ^C --- 172.17.0.3 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.086/0.165/0.470 ms / # ただし、デフォルトのbridgeネットワークではコンテナ名の名前解決が行えません。(デフォルトではDockerデーモンがDNS機能を提供していないとのこと) / # ping bridge-nginx ping: bad address 'bridge-nginx' / # ホストに戻って、bridge-nginxにhttpリクエストを送ります。nginxはデフォルトでは80番ポートでListenしているのでポートを指定せずリクエストを送ります。ホストも172.17.0.1のIPを持っているためコンテナ間と同じL2の通信となります。(alpineにcurlが入ってなかった。。) 作成時に8080にマッピングしていますが、理由は後ほど説明します。 docker@nw1-vm:~$ curl http://172.17.0.3 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> 問題なくレスポンスが返ってきますね。 外部からの通信 外部とは、図でいうと192.168.99.0/24が該当し、「ホストマシンの中のネットワーク」に含まれていないところとしています。 試しに192.168.99.1から、先程のコンテナ172.17.0.2にpingを送っても返ってきません。(192.168.99.111は、172.17.0.Xにルーティングしてくれません。) tohi  ~  ping 172.17.0.3 PING 172.17.0.3 (172.17.0.3): 56 data bytes 36 bytes from 175.129.17.97: Communication prohibited by filter Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 7bc0 0 0000 3b 01 9720 192.168.0.12 172.17.0.3 Request timeout for icmp_seq 0 36 bytes from 175.129.17.97: Communication prohibited by filter Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 4 5 00 5400 701f 0 0000 3b 01 a2c1 192.168.0.12 172.17.0.3 ^C --- 172.17.0.3 ping statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss 外部からの通信を受け付けるにはコンテナのポートをホストのポートにマッピングする必要があります。 bridge-nginxコンテナを作成した時ホストの8080ポートとコンテナの80ポートをマッピングしているため、192.168.99.111の8080ポートにアクセスするとbridge-nginxの80ポートに転送されbridge-nginxからレスポンスがあります。 直接ホストの80ポートにアクセスしてもホストは80をListenしていないのでレスポンスはありません。 tohi  ~  curl http://192.168.99.111:8080 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> tohi  ~  curl http://192.168.99.111:80 curl: (7) Failed to connect to 192.168.99.111 port 80: Connection refused tohi  ~  hostネットワークの接続と疎通確認 ホストのネットワーク情報を共有して使います。 例えば、先ほどbridgeネットワークでコンテナの80ポートとホストの8080ポートを紐付け外部からのアクセスを受け付けていましたが、 hostネットワークではポートの紐付けは必要ありません。bridge-nginxをこのネットワークに接続すると、ホストとネットワーク情報を共有することとなり、 外部から192.168.99.111:80へのアクセスが可能となります。 host-nginx2を作成しhostネットワークに接続 作成時、--networkオプションに引数としてネットワーク名を指定することで最初から指定したネットワークに所属させることができる。 この場合デフォルトのbridgeネットワークには自動で接続されないので注意 作成前にホストでListenしているポートを確認します。 docker@nw1-vm:~$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 280 10.0.2.15:22 10.0.2.2:54714 ESTABLISHED tcp 0 0 :::2376 :::* LISTEN tcp 0 0 :::22 :::* LISTEN docker@nw1-vm:~$ 80ポートはListenされていません。 次にhost-nginx2コンテナを作成します。 docker@nw1-vm:~$ docker run -d --name host-nginx2 --network host nginx a9da74b6fb649412d49e0e0510370b0b56cfea0b2ed6e6afcba0b135344f4561 docker@nw1-vm:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a9da74b6fb64 nginx "/docker-entrypoint.…" 3 seconds ago Up 3 seconds host-nginx2 docker@nw1-vm:~$ 作成後、ホストのListenポートを確認します。 docker@nw1-vm:~$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 36 10.0.2.15:22 10.0.2.2:54714 ESTABLISHED tcp 0 0 :::2376 :::* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::22 :::* LISTEN hostネットワークにnginxコンテナが作成されたことによってポートでListenしていることがわかります。 試しにbridgeネットワークでホストの8080ポートとコンテナの80ポートをマッピングした時のホストのListenポートを確認すると、しっかり8080ポートでListenされていることがわかります。 docker@nw1-vm:~$ docker run -d --name bridge-nginx2 -p 8080:80 nginx f1f34d127e518822363ecc1662f0e7b988ac5bd2d6d230c7289a4e95c721ed38 docker@nw1-vm:~$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f1f34d127e51 nginx "/docker-entrypoint.…" 2 seconds ago Up 1 second 0.0.0.0:8080->80/tcp bridge-nginx2 a9da74b6fb64 nginx "/docker-entrypoint.…" 2 minutes ago Up 2 minutes host-nginx2 docker@nw1-vm:~$ netstat -ant Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 10.0.2.15:22 10.0.2.2:54714 ESTABLISHED tcp 0 0 :::2376 :::* LISTEN tcp 0 0 :::8080 :::* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::22 :::* LISTEN docker@nw1-vm:~$ 通信確認 ここまででネットワークは下図の様になっています。 hostネットワークのnginxへアクセス 先程netstatコマンドで確認した様に、ホストの80ポートでListenしているため、ホストのIP:80とすることでアクセスできます。 bridgeネットワークにいるnginxと区別するためindex.htmlの内容を変更しました。 hostネットワークのhost-nginx2へアクセス tohi  ~  curl http://192.168.99.111 <h1>Host Network Container</h1> bridgeネットワークのbridge-nginxにアクセス tohi  ~  curl http://192.168.99.111:8080 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html> ポート番号によってそれぞれ別のコンテナにアクセスされていることがわかりました。 ユーザ定義のbridgeネットワークの接続と疎通確認 ユーザ定義のbridgeネットワークではデフォルトのbridgeネットワークでできなかった名前解決が可能となっている。 ユーザ定義のbridgeネットワーク作成 docker network createコマンドで新規ネットワークを作成。 docker network lsコマンドでネットワーク一覧を表示 docker@nw1-vm:~$ docker network create my_nw df1f71cba9fbe4d09a0cbbd61a50a098b95a749d112f59811c75e41ae25b23a5 docker@nw1-vm:~$ docker network ls NETWORK ID NAME DRIVER SCOPE af3424acd307 bridge bridge local f4b054a543f0 host host local df1f71cba9fb my_nw bridge local 23c0b52380c9 none null local docker@nw1-vm:~$ ユーザ定義のbridgeネットワークに接続 既存のbridge-nginx2は、 docker network disconnectコマンドでデフォルトbridgeネットワークから切断し docker network connectコマンドでユーザ定義のbridgeネットワークに接続します。 ※noneネットワーク以外であれば1つのコンテナを複数のネットワークに接続することは可能ですが、今回はわかりやすくするため既存のネットワークからは切断しています。 疎通確認のためalpine-linuxをユーザ定義bridgeネットワークに作成します。 docker@nw1-vm:~$ docker network disconnect bridge bridge-nginx2 docker@nw1-vm:~$ docker network connect my_nw bridge-nginx2 docker@nw1-vm:~$ docker run -itd --name bridge-alpine3 --network my_nw alpine c3a9558ee438f1939b73db4b1fb8702adfd9407b1c0fed003423667448743ef6 docker@nw1-vm:~$ docker network inspect my_nw [ { "Name": "my_nw", "Id": "df1f71cba9fbe4d09a0cbbd61a50a098b95a749d112f59811c75e41ae25b23a5", "Created": "2021-07-25T00:20:35.81237485Z", "Scope": "local", "Driver": "bridge", "EnableIPv6": false, "IPAM": { "Driver": "default", "Options": {}, "Config": [ { "Subnet": "172.19.0.0/16", "Gateway": "172.19.0.1" } ] }, "Internal": false, "Attachable": false, "Ingress": false, "ConfigFrom": { "Network": "" }, "ConfigOnly": false, "Containers": { "c3a9558ee438f1939b73db4b1fb8702adfd9407b1c0fed003423667448743ef6": { "Name": "bridge-alpine3", "EndpointID": "351a3422376daaed611c5b686b6c5e56cb62f8d7dc4e97c734579cc75ad53761", "MacAddress": "02:42:ac:13:00:03", "IPv4Address": "172.19.0.3/16", "IPv6Address": "" }, "f1f34d127e518822363ecc1662f0e7b988ac5bd2d6d230c7289a4e95c721ed38": { "Name": "bridge-nginx2", "EndpointID": "7ef1d91219bd4b9f1acf063ac9051c6ff72e217ab7f88f95389497b7594eda80", "MacAddress": "02:42:ac:13:00:02", "IPv4Address": "172.19.0.2/16", "IPv6Address": "" } }, "Options": {}, "Labels": {} } ] docker@nw1-vm:~$ 作成したmy_nwにbridge-nginx2が接続されていることが確認できます。 疎通確認 IPアドレスでの通信はもちろん可能ですが、ユーザ定義bridgeネットワークではコンテナ名での通信が可能です。 docker@nw1-vm:~$ docker exec -it bridge-alpine3 /bin/sh / # ping 172.19.0.2 PING 172.19.0.2 (172.19.0.2): 56 data bytes 64 bytes from 172.19.0.2: seq=0 ttl=64 time=0.286 ms 64 bytes from 172.19.0.2: seq=1 ttl=64 time=0.104 ms ^C --- 172.19.0.2 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.104/0.195/0.286 ms / # ping bridge-nginx2 PING bridge-nginx2 (172.19.0.2): 56 data bytes 64 bytes from 172.19.0.2: seq=0 ttl=64 time=0.130 ms 64 bytes from 172.19.0.2: seq=1 ttl=64 time=0.093 ms 64 bytes from 172.19.0.2: seq=2 ttl=64 time=0.088 ms 64 bytes from 172.19.0.2: seq=3 ttl=64 time=0.096 ms ^C --- bridge-nginx2 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.088/0.101/0.130 ms / # 外部からのアクセスはbrigdeネットワークと同様にマッピングしたポートへ通信する必要があります。 ここまでやるとネットワーク図は以下の様になります。 最後に Dockerのネットワークについて基本的なところは以上になるかと思います。 自分用の面が強いですが、参考になれば幸いです。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Rails, AWS, Dockerでポートフォリオ作成

リンク 【ポートフォリオ】 https://tasty-life.site/ 【Github】 https://github.com/YukiIshizaki0525/TastyLife はじめに 独学でサーバーサイド、フロントエンド、インフラを1から勉強し、Webアプリを作成しました。 本記事で、作成で苦労した点、各種機能、機能実装で参考になったサイトなどを記載いたしますので、現在ポートフォリオ作成中の未経験エンジニアやこれからポートフォリオを作ろうと考えている方のヒントとなれば幸いです。 機能実装方法やテストの書き方などより詳細な内容については別途Qiitaを投稿する予定ですので、更新をお待ちいただければと思います。 本記事についてのご質問や気になった点などがあればできる限り回答いたしますのでTwitterのDMやコメントでお知らせください。 【Twitterアカウント】 https://twitter.com/Luke19770525 概要 一人暮らしの自炊継続のモチベーションアップ及び脱マンネリ化したいという思いから制作 制作背景 私自身一人暮らしで、日々自炊を行っていて、以下のことが課題と感じています。 作る料理がマンネリ化してしまい、モチベーションが下がり、自炊を突然やめてしまう 一人暮らしの自炊についての相談できる機会がない 冷蔵庫に保管している食材を管理できていないため、腐らせてしまったり余っているのに買ってしまう そこで、上記課題を解決できる 一人暮らしの方の自炊を応援するアプリケーション を作成しようと決意しました。 今後の展望 自炊を行う知り合いに使ってもらっていて、ユーザーの貴重な意見を参考に日々改善を行っています。 今後、追加予定の機能及び変更点を5点ほど列挙します。 - アプリケーション自体をVue.jsでSPA化 - APIの導入 - 現在の食材管理状況を毎日18:00にメールで登録済みメールアドレスに配信 - 材料や作り方をドラッグ&ドロップして入れ替えられる仕様 - 作り方の画像プレビュー機能の追加 工夫した点 UI/UX - レシピを見て料理をする際はスマートフォンで見ることも多いのでレスポンシブデザインにしたこと - ページタイトル、文字色、ボーダー等の色を統一したこと - 一覧ページへ移動、削除、送信などをアイコンにして、直感的に操作できるようにしたこと - ホバーアクションやクリックアクションなどCSSアニメーションを取り入れ、動きのあるサイト構成にしたこと - 使いやすい導線設計 機能面 - 一人暮らしでの自炊での悩み(マンネリ化・食材管理など)を解決できるような機能を作成して、一般的なレシピサイトとの差別化を図ったこと - 作りたい料理が決まらない日が多いため、タグ検索機能を追加し、作りたい料理を決められる手助けとなるようにしたこと - 自炊を続けている方の相談や関心が高い相談を見て、自身の生活にも取り入れられるよう、相談のソート機能を追加したこと - 保存中の食材を把握しきれず無駄な買い足しや食材廃棄してしまっていたため、無駄な買い足しや食材廃棄を未然に防ぎ、余り物を有効活用できるよう、保存中の食材管理機能を追加したこと テスト - バリデーションやデザインに不備なく、ユーザーが安心してご利用いただけるようモデルスペック及びシステムスペックを十分に実施 ModelSpec結果 SystemSpec結果 学習で参考になったサイトや教材 ◎は非常に参考になった教材です。(個人の感想です) フロントエンド HTML/CSS/JavaScript ◎【JavaScript&CSS】ガチで学びたい人のためのWEB開発徹底実践(フロントエンド編) 【JS】ガチで学びたい人のためのJavaScriptメカニズム サーバーサイド Ruby ◎プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで Rails ◎Ruby on Rails チュートリアル ◎現場で使える Ruby on Rails 5速習実践ガイド ◎フルスタックエンジニアが教える 即戦力Railsエンジニア養成講座 パーフェクト Ruby on Rails テスト基盤 RSpec ◎Everyday Rails - RSpecによるRailsテスト入門 ◎【Rails】はじめてのRSpec!テストコードを書こう! データベース ◎BigQuery で学ぶ非エンジニアのための SQL データ分析入門 ◎はじめてのSQL ・データ分析入門 -データベースのデータをビジネスパーソンが現場で活用するためのSQL初心者向コース インフラ Docker ◎Docker超入門講座 合併版 | ゼロから実践する4時間のフルコース ◎ゼロからはじめる Dockerによるアプリケーション実行環境構築 【Rails AWS Docker】既存Ruby on Rails + MySQLアプリをDockerで構築し、AWSにデプロイする(1) AWS ◎AWS:ゼロから実践するAmazon Web Services。手を動かしながらインフラの基礎を習得 ◎サルでもできる!? Rails6 のアプリをAWS EC2にデプロイするまでの全手順【前半】(VPC, RDS, EC2, Capistrano) 苦労した点 フロントエンド レスポンシブデザインのため、scssファイルを多く管理するのが大変でした。 JavaScriptでイベント発火時にエラーは出ないが挙動がおかしい場面が多く修復するのに苦労し、1日悩んでわからないことも多く断念したものもあります。今後はVue.jsをガッツリ勉強して対応できるようにしたい サーバーサイド 【レシピの材料及び作り方の非同期追加及び削除】の機能実装は苦労しました。Cocoon(Gem)を入れて当初実装していましたが、デザインが当たらなかったりなど、ブラックボックスに感じたので模索しながらGemを使わずに実装しました。こちらのサイトが唯一あって助かりました。 create a nested form in rails from scratch devise及びgmail認証 deviseもブラックボックスでカスタマイズするのに苦労しました。特にメール認証ではgmailにメールが届かないことが多く挫折しかけました。メール文章もデフォルトのものがあたってしまい、メール文章をカスタマイズするのにも一苦労しました。Qiitaの記事などを参考になんとか自身がイメージする形に仕上がったので良かったです。その関連でActionMailerについての知見も増え、gmailを使った退会処理機能などを実装することができました。 インフラ AWSとDockerの連携 ポートフォリオ作成初期にAWSとDockerを構築してから自動デプロイできるように努力しましたが、当初は敷居が高いと感じ、挫折しました。付け焼き刃では通用しないと思い、サイトや書籍を参考にチャレンジしたら、スムーズに構築することができました。何事も基礎がないとダメってことですね。 使用画面 トップページ ログインページ レシピ一覧(材料・レシピ名での検査、タグでのソートが可能です) レシピ詳細とコメント 相談一覧(回答数・気になる数などでソートが可能です) 相談詳細とコメント ユーザー詳細 食材管理ページ(自身のものしか見れません) 使用技術 フロントエンド HTML/CSS/Sass JavaScript(ES6) バックエンド Ruby 2.6.5 Rails 6.0.3 テスト基盤 RSpec 3.9 FactoryBot 4.10.0 データベース MySQL 5.7 インフラ Docker 20.10.7 Docker Compose 1.29.2 AWS(VPC, EC2, IAM, RDS, InternetGataway, SecurityGroup, Subnet, Route53, ALB, ACM, S3, CloudFront) Nginx 1.15.8 AWS構成図 ER図 機能一覧 基本機能 ユーザー新規登録(Gmail認証) ログイン・ゲストユーザーログイン ログアウト ログインセッション保持 ログインパスワード再設定(Gmail認証) アカウント認証メール再送 アカウントの凍結解除メール送信 ユーザー退会(論理削除) 退会済みユーザーアカウント復旧機能(Gmail認証) ユーザーアカウント情報変更(メールアドレス・プロフィール画像・ユーザー名・パスワード) メールアドレス変更(Gmail認証) フォロー中ユーザー一覧及びフォロワー一覧閲覧 ユーザーフォロー ユーザー詳細及びマイページ表示(レシピ・いいねしたレシピ・相談・気になっている相談・食材管理) ユーザー一覧 レシピに関する機能 ログイン済み レシピ投稿 材料及び作り方の非同期追加及び削除 レシピの画像添付(画像プレビュー可能) 作り方に画像添付 関連タグ付け(既定6つのタグ複数選択可能) レシピ一覧 レシピ詳細 レシピ編集(投稿したユーザーのみ) レシピ削除(投稿したユーザーのみ) コメント閲覧 コメント投稿 コメントに対する返信 コメント削除(投稿したユーザーのみ) レシピにいいねをつける レシピいいね数確認 ワードで検索(レシピ名及び材料名) 関連タグで検索 タイムライン(自身及びフォローしている方の投稿のみ表示) 未ログイン レシピ一覧 レシピ詳細 コメント閲覧 ワードで検索(レシピ名及び材料名) 関連タグで検索 相談に関する機能 ログイン済み 相談投稿 相談一覧 相談詳細 相談編集(投稿したユーザーのみ) 相談削除(投稿したユーザーのみ) 相談ソート(投稿が新しい順・投稿が古い順・気になるが多い順・回答数が多い順) コメント閲覧 コメント投稿 コメントに対する返信 コメント削除(投稿したユーザーのみ) 相談に気になる追加 相談気になる数確認 未ログイン 相談一覧 相談詳細 コメント閲覧 相談ソート 食材管理に関する機能 ログイン済みかつ自身のみ 保管中の食材追加・登録・編集・削除 食材画像,数量,個数,賞味期限,メモの登録 賞味期限までの日数確認 最後に ポートフォリオ作成は転職活動のために作成するのではなく、自身やユーザーの課題解決のために、ポートフォリオ制作を行うことに注力したので、非常に達成感があります。 ポートフォリオを使っていただいた方からありがたいことに改善点をいただいているので、作成途中よりも作成後の方がIssueが多いです(笑) ですが、実際にユーザーの生の声を聞いて、ユーザーのことをより考えながら改善や機能実装をしようと開発を進めているため、以前よりも幸せに感じながら実装ができています。 転職後も新しい技術に触れることが多いと思うので、インプットした後に本ポートフォリオに取り入れて、アウトプットの場にも使いたいと思います。 ここまでご覧いただきましたありがとうございました!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

【500エラー】【AWS】RDSに日本語が保存できない問題 Rails on Docker

docker環境でrails6アプリを構築し、苦労してようやくEC2上にアプリをデプロイできたと思ったら、 何故かdeviseのユーザー登録時メール認証機能(comfirmable)、お問い合わせメール機能、ゲストログイン機能が500エラー。。。 メールに関する部分だけがエラーになっているからてっきりSMTPサーバーが機能していないのかな?などと推測し、 SESの設定を見直すも・・・・ 解決できず。。 原因:RDSで作成したMySQLのDBに日本語が保存できないこと RDSではDefaultでcharacter-setにlatin1が割り当てられるため、日本語を利用する際はutf8などに変更してあげる必要があったのでした。 そのためRDSで設定したMySQLに関するエラーが発生していました。 それに気づかずてっきりSMTPサーバー関係のエラーだと決めつけて数日もがいてました。。 そもそも私はログイン済みユーザーじゃないと新規投稿機能だったりフォローだったり、全ての機能を利用できないように制限をかけていたので 他のページの確認ができていなかったのですが、 本当はメールに関する部分だけがエラーになっていたのではなくて、 全体がエラーになっていたんだと思います。。。 解決につながったこと:エラーログの確認 エラーがどこで発生しているのか、原因の切り分けも大事ですが、エラーログを確認することが何より最も重要だと気づかされました。 docker環境でつくったアプリをEC2にデプロイしたら、本番環境のみエラーになってしまう。 開発環境ではエラーないのに。 その場合はどこでエラーログを見られるの?? そもそもエラーログ出す方法なんてないんじゃないか?? などと一週間くらいパニック状態でしたが(笑) ログの出し方が分かったことで2、3時間くらいで解決できてしまいました!!! エラーログの出し方 [ec2]$ cd /var/www/アプリ名 [ec2]$ docker-compose exec app bash root@f4658ed2b15e:/var/www/アプリ名# cd /var/www/アプリ名 root@f4658ed2b15e:/var/www/アプリ名# ls root@f4658ed2b15e:/var/www/アプリ名# cd log root@f4658ed2b15e:/var/www/アプリ名/log# ls root@f4658ed2b15e:/var/www/アプリ名/log# tail -f production.log tail -fを使うことで、ページにアクセスしたときのエラーをリアルタイムで見ることができて便利です。 解決策:RDSの設定変更 下記記事の通りに設定したら解決しました。ありがとうございます!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

開発学習備忘録

開発に関する備忘録 Gitコマンド git add -A git commit -m "コメント" Git-flowに関する参考サイト https://qiita.com/KosukeSone/items/514dd24828b485c69a05 Vimコマンド 参考サイト https://qiita.com/hide/items/5bfe5b322872c61a6896 Railsコマンド Dockerコマンド docker-compose stop docker-compose up -d その他 ローカルホストの接続先 http://localhost:3000/ figma参考サイト https://qiita.com/Hrioaki/items/d428d8318780a47f87ff VSCodeショートカット参考サイト https://qiita.com/naru0504/items/99495c4482cd158ddca8
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

docker php-fpm に ldap拡張を組み込む

デフォルトでは php-fpm なコンテナに ldap拡張が入ってないので組み込む場合の Dockerfile FROM php:8-fpm ARG UID=1000 ARG GID=1000 RUN useradd -m -u ${UID} docker # node.js for yarn RUN curl -sL https://deb.nodesource.com/setup_16.x | bash - RUN apt-get install -y nodejs # yarn (webpack etc,...) RUN apt remove cmdtest && apt remove yarn RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add - RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list RUN apt-get update \ && apt-get install -y libldb-dev libldap2-dev \ && ln -s /usr/lib/x86_64-linux-gnu/libldap.so /usr/lib/libldap.so \ && ln -s /usr/lib/x86_64-linux-gnu/liblber.so /usr/lib/liblber.so \ && apt-get install yarn \ && docker-php-ext-install pdo_mysql ldap \ && apt install -y git unzip USER ${UID}:${GID} COPY --from=composer:latest /usr/bin/composer /usr/bin/composer
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DockerでJupyterLab環境を作る - Streamlit編

Streamlitを表示させながらJupyterLabでコードを書きたいと思い、 Dockerで環境を作成しました。 前提の話はこちらの記事で書いています。 基本的には上記の内容とほぼ変わらないですが、 docker-compose.ymlでimageを2つ作成している点がことなります。 フォルダ構成 Dockerfile docker-compose.yml requirements.txt src └ app.py Dockerfile FROM python:3 COPY requirements.txt . RUN pip3 install --upgrade pip && \ pip3 install --no-cache-dir -r requirements.txt && \ pip3 install jupyterlab WORKDIR /src COPY /src /src requirements.txt streamlit pandas app.py 最初は空でも問題ないです。 import streamlit as st st.write('Hello Streamlit') docker-compose.yml version: '3' services: jupyterlab: restart: always build: context: . dockerfile: Dockerfile container_name: jupyterlab working_dir: '/src' tty: true volumes: - ./src:/src ports: - '8080:8080' command: jupyter-lab --ip 0.0.0.0 --port=8080 --allow-root --no-browser --NotebookApp.token='' stremlit: restart: always build: context: . dockerfile: Dockerfile container_name: stremlit working_dir: '/src' tty: true volumes: - ./src:/src ports: - '8501:8501' command: streamlit run app.py jupyterlabの方は--NotebookApp.token=''オプションを追加してトークンの入力なしで開けるようにしました。 streamlitではworkind_dirで指定したフォルダにapp.pyがあることが重要です。 これらを用意してdockerコマンドを実行 docker compose up localhost:8080でJupyterLab localhost:8501でStreamlitが表示されます。 JupyterLabの拡張機能を入れるとimageの作成に時間がかかるので 省略していますが、実際には入れて環境構築します。 その話はこちらの記事でまとめています。
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

DockerでJupyterLab環境を作る - 拡張機能追加

DockerでJupyterLab環境を作るでは基本的なJupyterLab環境構築の方法をしめしたので、 この記事では拡張機能の設定をしていきたいと思います。 オレオレJupyterlab環境をDockerで作ったを参考に最低限必要なコードに絞ってみました。 jupyterlab-kiteのインストール jupyterlab-kiteで必要なDockerfile FROM python:3 # Node.jsのインストール RUN curl -sL https://deb.nodesource.com/setup_12.x |bash - \ && apt-get install -y --no-install-recommends \ nodejs # pythonライブラリのインストール COPY requirements.txt . RUN pip3 install --upgrade pip && \ pip3 install --no-cache-dir -r requirements.txt \ && rm -rf ~/.cache/pip # JupyterLabと拡張機能のインストール RUN pip3 install --upgrade --no-cache-dir \ jupyterlab \ 'jupyterlab-kite>=2.0.2' \ && jupyter labextension install \ '@kiteco/jupyterlab-kite' \ # jupyter-kiteのインストール RUN cd && \ wget https://linux.kite.com/dls/linux/current && \ chmod 777 current && \ sed -i 's/"--no-launch"//g' current > /dev/null && \ ./current --install ./kite-installer WORKDIR /src COPY /src /src jupyterlab-kiteをインストールするためにはNode.jsが必要なので、 冒頭のNode.jsのインストールの箇所が必要になってきます。 それとjupyter-kiteのインストールの箇所もなぜ必要なのかわからず、 外して実行すると下記のようなエラーが表示されました。 jupyter-kiteの実行にはKite Engineのデスクトップアプリケーションが必要ですと表示されます。 docker-compose.yml docker-compose.ymlファイルには--NotebookApp.token=''を追加しました。 version: '3' services: jupyterlab: restart: always build: context: . dockerfile: Dockerfile container_name: jupyterlab working_dir: '/src' tty: true volumes: - ./src:/src ports: - "8080:8080" command: jupyter-lab --ip 0.0.0.0 --port=8080 --allow-root --no-browser --NotebookApp.token='' これで-dのバックグラウンドでの実行でもトークンの入力なくJupyterLabを開くことができます。 docker compose up -d 機能テストで追加したい場合 前の記事で書いているコンテナの中に入ってインストールすることが可能です。 docker exec -it [コンテナ名] bash その中で試してみて動けばDockerfileに追記するというやり方もできます。 私の場合は後述するVariable Inspectorのインストールができなくて、 エラー内容を確認するために、コンテナに入って実行しました。 その他欲しい機能を追加 追加したい機能は下記を参考にさせてもらいました。 この中から下記3つを入れるのにハマった点が2つありました。 Variable Inspector Table of Contents jupyterlab_code_formatter  Variable Inspector Variable Inspectorを入れる際は jupyter labextension install @lckr/jupyterlab_variableinspectorはそのままでは使えませんでした。 こちらに書かれていrequirementsに書かれているライブラリを全てイントールすると問題なく動きます。 ただ、それだと不要なライブラリも多いので代わりに pip3 install lckr-jupyterlab-variableinspectorを使っても問題なく動きました。 jupyterlab_code_formatter 最初参考記事と同じようにyapfを使おうと思ったらisortが入っていないというエラーがでました。 検索して違いを調べた結果、この記事を参考にblack, isortを使っていこうかなと思ってその2つを選択しています。 root userの設定 コンテナ内で拡張機能を追加しているとroot userとして実行してという WARNINGがでてきたので、その設定もDockfileに追加した方がよさそうです。 Kiteに加えて下記3つをデフォで使うのにDockerfikeを変更しました。 最終的なDockerfile 現状はどこで何を入れているのか把握しやすいように拡張機能ごとに RUNを分けて実行していますが、慣れたたら混ぜて実行するかもしれないです。 4つの拡張機能追加 FROM python:3 USER root RUN curl -sL https://deb.nodesource.com/setup_12.x |bash - \ && apt-get install -y --no-install-recommends \ nodejs \ yarn # install python library COPY requirements.txt . RUN pip3 install --upgrade pip && \ pip3 install --no-cache-dir -r requirements.txt \ && rm -rf ~/.cache/pip # install jupyterlab&kite RUN pip3 install --no-cache-dir \ jupyterlab \ 'jupyterlab-kite>=2.0.2' \ && jupyter labextension install \ '@kiteco/jupyterlab-kite' # install jupyterlab_variableinspector RUN pip3 install --upgrade --no-cache-dir \ black \ isort \ jupyterlab_code_formatter \ && jupyter labextension install \ @ryantam626/jupyterlab_code_formatter \ && jupyter serverextension enable --py jupyterlab_code_formatter # install jupyterlab_variableinspector RUN pip3 install --no-cache-dir lckr-jupyterlab-variableinspector # install other_extentions RUN jupyter labextension install \ @jupyterlab/toc # install jupyter-kite RUN cd && \ wget https://linux.kite.com/dls/linux/current && \ chmod 777 current && \ sed -i 's/"--no-launch"//g' current > /dev/null && \ ./current --install ./kite-installer WORKDIR /src COPY /src /src 拡張機能に関する情報 コンテナの中に入って下記のコマンドを実行すると今の入っている拡張機能一覧が表示できます。 拡張機能一覧表示 jupyter labextension list 出力結果 JupyterLab v3.0.16 /usr/local/share/jupyter/labextensions @jupyter-widgets/jupyterlab-manager v3.0.0 enabled OK (python, jupyterlab_widgets) @kiteco/jupyterlab-kite v2.0.2 enabled OK (python, jupyterlab_kite) @ryantam626/jupyterlab_code_formatter v1.4.10 enabled OK (python, jupyterlab-code-formatter) @lckr/jupyterlab_variableinspector v3.0.9 enabled OK (python, lckr_jupyterlab_variableinspector) Other labextensions (built into JupyterLab) app dir: /usr/local/share/jupyter/lab @jupyterlab/toc v5.0.12 enabled OK 動かない場合はserverextentionも見るとよいそうです。 詳細はわかっていないです。 jupyter serverextension list 出力結果 config dir: /root/.jupyter jupyterlab_code_formatter enabled - Validating... jupyterlab_code_formatter 1.4.10 OK config dir: /usr/local/etc/jupyter jupyterlab enabled - Validating... jupyterlab 3.0.16 OK jupyterlab_code_formatter enabled - Validating... jupyterlab_code_formatter 1.4.10 OK
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む