20210907のdockerに関する記事は10件です。

webhookテスト

マークダウンの見出し1 マークダウンのプレーンなテキスト コードスニペット 2つ目のマークダウン 見出し2
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

webhookテスト

マークダウンの見出し1 マークダウンのプレーンなテキスト コードスニペット 2つ目のマークダウン 見出し2
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

webhookテスト

マークダウンの見出し1 マークダウンのプレーンなテキスト コードスニペット 2つ目のマークダウン 見出し2
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

webhookテスト

マークダウンの見出し1 マークダウンのプレーンなテキスト コードスニペット 2つ目のマークダウン 見出し2
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

webhookテスト

マークダウンの見出し1 マークダウンのプレーンなテキスト コードスニペット 2つ目のマークダウン 見出し2
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

端的にdocker基礎の整理(1)

はじめに 現場に出たばかりの駆け出しがDockerを使ってるので、なるべく端的に知識をまとめてみました! ふーむ、全然わからんということで。 一歩ずつ進んでいきます:D 目次 Dockerの特徴 コンテナ イメージ Dockerfile マウント 参考文献 Dockerの特徴 dockerの利点 ⑴コンテナ型の超軽量サーバ仮想化製品 ⑵コンテナ内は実行環境として独立している ⑶コンテナはリソース消費量が少ない dockerの欠点 ⑴Linuxカーネルしか動作しない ⑵完全な分離ではない コンテナ コンテナとは、アプリケーションを実行できる環境のこと つまり、コンテナ≒サーバ イメージから作られる ・Appachコンテナ ・dbコンテナ イメージ イメージは、コンテナの元になる設定ファイル(OS・ミドルウェアの情報とか) そのイメージからコンテナを作成する。 イメージはDucker Hub等から引っ張られる Dockerfile Dockerfileは、Dockerイメージを作成するための設定を記述したテキストファイルです。 Dockerfileにコンテナの環境設定を記述し、それをビルドするとイメージが作成されます。 マウント ホストPCの指定箇所をコンテナ内の指定箇所と対応させ共有することのできる機能です。 3通りのマウントの仕方がある。(最初はvolumeから抑えとくといいと思いました。) ・volumeマウント ・bind マウント ・tmpfs マウント Dockerを用いて開発環境構築をする際に意識すること 開発環境の構築を行う際, Dockerを使ってチーム等で開発を進める際には, 以下の3つを共有できる状態にすることを基本の形として意識するといい。 Dockerfile, Composefile プログラムソースファイル サーバ設定ファイル 加えて、シンプルなコンテナを立てただけではコンテナのデータを維持することができない。 コンテナのデータを永続化させる方法を考える。 結局、コンテナは(ローカル)ホスト側のファイルシステムと隔離されているから。 それを解決流手法としてマウントを考える。 いきなり「dockerで開発環境構築しておいて!!」って言われてもわからんので、 Dockerの基礎用語と概要を理解してからWordpress環境をdockerで構築しようみたいなdocker-composeのチュートリアルみたいなのをやってみると分かりやすいと思いました。 参考文献 Dockerで環境構築するための最低限の概念理解 公式doc
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

VSCode x DockerでXdebugを使えるようにする

はじめに この記事では、Visual Studio Code、Docker Desktop の導入方法は説明しません。 Xdebugのバージョンは2系と3系を使います。 環境 macOS Big Sur --version 11.3 Visual Studio Code --version 1.60.0 Docker Desktop --version 3.6.0 Visual Studioで必要な拡張機能をインストール felixfbecker.php-debug をインストールしてください ディレクトリ構成 . ├── .vscode │   └── launch.json ├── Dockerfile ├── docker-compose.yml ├── php.ini └── src └── index.php Dockerfile Xdebug2を使う場合 FROM php:7.4-apache RUN pecl install xdebug-2.8.1 \ && docker-php-ext-enable xdebug WORKDIR /var/www/html Xdebug3を使う場合 FROM php:7.4-apache RUN pecl install xdebug \ && docker-php-ext-enable xdebug WORKDIR /var/www/html docker-compose.yml version: "3.7" services: app: build: '.' ports: - 8088:80 volumes: - ./src:/var/www/html/ - ./php.ini:/usr/local/etc/php/php.ini php.ini Xdebug2を使う場合 [xdebug] xdebug.default_enable=1 xdebug.idekey=VSCODE xdebug.remote_autostart=1 xdebug.remote_enable=1 xdebug.remote_host=host.docker.internal xdebug.remote_log=/tmp/xdebug.log xdebug.remote_port=9000 Xdebug3を使う場合 [xdebug] xdebug.client_host=host.docker.internal xdebug.client_port=9000 xdebug.idekey=VSCODE xdebug.log=/tmp/xdebug.log xdebug.mode=debug xdebug.start_with_request=yes 2021/09/08 修正 xdebug.remote_host=docker.for.mac.localhostでも動きますが現在非推奨です。 /src/index.php <?php phpinfo(); ./vscode/launch.json てんとう虫のマークを押して「launch.jsonファイルを作成します。」を押します。 PHPを選択します。 作業ディレクトリ配下に「.vscode」ディレクトリと「lauch.json」が作成されます。 launch.json を編集します。 { "version": "0.2.0", "configurations": [ { "name": "Listen for Xdebug", "type": "php", "request": "launch", "port": 9000, "pathMappings": { "/var/www/html/": "${workspaceRoot}/src" }, }, { "name": "Launch currently open script", "type": "php", "request": "launch", "program": "${file}", "cwd": "${fileDirname}", "port": 9000, "runtimeArgs": [ "-dxdebug.start_with_request=yes" ], "env": { "XDEBUG_MODE": "debug,develop", "XDEBUG_CONFIG": "client_port=${port}" } } ] } Dockerコンテナを起動 ターミナルを開き、作業ディレクトリへ移動します。 user@Mac ~ % cd /path/to/a/directory/ コンテナをビルドした後に起動します。 ちょっと時間がかかるかもしれません。 user@Mac directory % docker-compose build user@Mac directory % docker-compose up -d ブラウザで http://localhost:8088/index.php にアクセスし、 phpinfoの画面が表示されればOKです。 VSCodeでデバッグする ブレークポイントを付ける デバッグを開始する 「Listen for Xdebug」を選び「▷」ボタンを押すと下の画面のようになります。 http://localhost:8088/index.php を更新すると下の画面のようになり、デバッグができます!
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Artifact Registry から GKE にデプロイ

概要 ・コンテナイメージを管理するサービスである Artifact Registry に nginxイメージを push ・Artifact Registry から GKE にデプロイ ・nginxをインターネットに公開 環境 Cloud SDK と Docker がインストール済みの環境で実行 $ gcloud -v Google Cloud SDK 355.0.0 bq 2.0.71 core 2021.08.27 gsutil 4.67 $ docker -v Docker version 20.10.8, build 3967b7d 手順 手順は以下のとおりです。 ① Artifact registryにリポジトリを作成 ② nginxイメージを公式からpull ③ nginxイメージにタグづけ ④ イメージをArtifact registryにpush ⑤ GKEクラスター作成 ⑥ GKEクラスターにnginxコンテナをデプロイ ⑦ nginxを公開 ① Artifact registryにリポジトリを作成 nginxイメージを保存するためのリポジトリを、事前に作成する必要があります。 右上の「リポジトリを作成」から、以下の設定でリポジトリを作成します。 名前   :test-repository 形式   :Docker リージョン:asia-northeast1(東京) 次に、作成したリポジトリへのリクエストを認証するために、以下のコマンドを実行します。 gcloud auth configure-docker asia-northeast1-docker.pkg.dev これで、イメージをpushする準備ができました。 次に、イメージを準備します。 ② nginxイメージを公式からpull 以下のコマンドで公式のnginxイメージをpullしましょう。 docker pull nginx イメージのpullに成功していたら、以下のコマンドでnginxイメージが表示されます。 docker images ③ nginxイメージにタグづけ イメージをリポジトリにpushするために、リポジトリ名でタグづけする必要があります。 docker tag nginx asia-northeast1-docker.pkg.dev/プロジェクト名/test-repository/nginx-image このコマンドを実行することで、nginxイメージに「asia-northeast1-docker.pkg.dev/プロジェクト名/test-repository/nginx-image」というタグが付きます。 ④ イメージをArtifact registryにpush 以下のコマンドで、イメージをリポジトリにpushします。 docker push asia-northeast1-docker.pkg.dev/プロジェクト名/test-repository/nginx-image リポジトリにイメージがpushされました。 これでArtifact registryでの作業は完了です。 ⑤ GKEクラスタ作成 次にGKEクラスタを作成します。 「GKE Standard」を選択し、全てデフォルトの設定のまま、「作成」を押します。 クラスターの作成には、数分かかります。 ⑥ GKEクラスタにnginxコンテナをデプロイ 作成したGKEクラスタにnginxコンテナをデプロイしていきましょう。 まず、作成したGKEクラスタに接続できるようにするために、以下のコマンドを実行します。 gcloud container clusters get-credentials cluster-1 --zone us-central1-c --project プロジェクト名 これで、GKEクラスタに接続できるようになりました。 次に、3つのPodを作成するdeploymentをデプロイします。 定義ファイルは以下の通りです。 deployment.yaml apiVersion: "apps/v1" kind: "Deployment" metadata: name: "nginx-1" namespace: "default" labels: app: "nginx-1" spec: replicas: 3 selector: matchLabels: app: "nginx-1" template: metadata: labels: app: "nginx-1" spec: containers: - name: "nginx-image-1" image: "asia-northeast1-docker.pkg.dev/プロジェクト名/test-repository/nginx-image:latest" この定義ファイルの存在するディレクトリで次のコマンドを実行します。 kubectl apply -f deployment.yaml deploymentがうまくデプロイできたか確認します。 kubectl get deployments NAME READY UP-TO-DATE AVAILABLE AGE nginx-1 3/3 3 3 46s ⑦ nginxを公開 deploymentがデプロイできたら、LoadBalancerを使ってインターネットに公開します。 定義ファイルは以下の通りです。 loadbalancer.yaml apiVersion: "v1" kind: "Service" metadata: name: "nginx-1-service" namespace: "default" labels: app: "nginx-1" spec: ports: - protocol: "TCP" port: 80 selector: app: "nginx-1" type: "LoadBalancer" この定義ファイルの存在するディレクトリで次のコマンドを実行します。 kubectl apply -f loadbalancer.yaml うまく公開できたかチェックしましょう。 kubectl get services で表示されるLoadBalancerの外部IPアドレスに対して、curlを実行します。 ※ 外部IPアドレスが表示されるまで、数分かかる可能性があります。 curl -i {外部IPアドレス}:80 HTTP/1.1 200 OK Server: nginx/1.21.1 . . . (省略) 上手く公開できていれば、ステータスコード200が返ってきます。 最後に Artifact Registoryにpushしたnginxイメージを、GKEにデプロイし、公開するまでを説明しました。 お疲れ様でした。 参考
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

Dockerコンテナを立ち上げるときのdetachedモードとは?

前提 -dオプションをなんとなくつけていたので、調べました。忘れないように記録しておきます。 まず前提として、Dockerはクライアント/サーバアプリケーションです。クライアント上でコンテナを作成するコマンドが叩かれると、クライアントがサーバにリクエストを行い、コンテナ作成はサーバ上で実行されます。 -dをつけるとdetachedモードでコンテナを起動 detachedモードだと、バックグラウンドでコンテナを起動します。つまり、クライアントがリクエストをしている間に、クライアントは終了します。detachedモードでコンテナを起動すると、そのまま他のコマンドを実行することが出来ます。つまり、起動した後も普通のターミナルとして使うことが出来ます。 -dをつけないとforegroundモードでコンテナを起動 逆は、フォアグラウンドでコンテナを起動します。先程と異なり、クライアントは終了しません。foregroundモードで起動すると、実行中のプロセスに対してコマンドをインタラクティブに入力することが出来ます。 間違いがありましたら、コメントでご指摘いただけると有り難いです。 参考 https://stackoverflow.com/questions/34029680/docker-detached-mode#comment110725353_34029977
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む

nginxのリバースプロキシ設定とNuxt.jsでハマった話

状況 Dockerでnginxとnode環境(Nuxt.js)を構築して、リバースプロキシを介してNuxtアプリにアクセスすることを試みた。 dokcer-compose.yml version: '3.9' services: proxy: image: nginx:1.21.0 volumes: - ./proxy/nginx.conf:/etc/nginx/nginx.conf ports: - '80:80' web: build: context: ./web dockerfile: Dockerfile command: yarn dev volumes: - ./web:/app tty: true environment: PORT: 3000 HOST: 0.0.0.0 ports: - '3000:3000' nginx.conf events {} http { server { listen 80; server_name localhost; location / { proxy_pass http://host.docker.internal:3000/; } } } この設定で、http://localhost/ へアクセスすると、リバースプロキシを介してNuxtアプリにアクセスできる。 しかし、途中でlocationを/から/app/に変更して、http://localhost/app/ の形でアクセスできるようにしたくなった。 nginx.conf events {} http { server { listen 80; server_name localhost; location /app/ { # ここを変更 proxy_pass http://host.docker.internal:3000/; } } } nginx.confを書き換えて、http://localhost/app/ にアクセスしたところ、こんなエラーが発生した。 [error] 25#25: *1 open() "/etc/nginx/html/_nuxt/runtime.js" failed (2: No such file or directory) ブラウザにはLoading Circleが表示されているので、Nuxtアプリ自体にはアクセスできているようだが、読み込めていないファイルがあるらしい。 エラー表記から_nuxt/runtime.jsの参照先がおかしいことがわかる。 本来であれば、localhost:3000にホストされている_nuxt/runtime.jsを参照したいところが、localhostにホストされている_nuxt/runtime.jsを見に行ってしまっている。 解決までの道のり まず、NuxtのbaseURLを/から/app/に変更した。 nuxt.config.js export default { // これを追記 router: { base: '/app/' } } こうすることで、localhostではなく、localhost/appにホストされている_nuxt/runtime.jsを参照することになり、リバースプロキシによってlocalhost/appからlocalhost:3000へ飛ばされるので、結果的にlocalhost:3000にホストされている_nuxt/runtime.jsを見に行くことになる。 よし、解決! と思ったが、別の問題が発生した。 リダイレクトが無限に繰り返されるようになってしまった。 メカニズムとしてはこんな感じ。 localhost/appにアクセス リバースプロキシがlocalhost:3000に読み替え NuxtのbaseURLは/app/なので、localhost:3000からlocalhost:3000/appにリダイレクト 結果的にURLはlocalhost/appになる 1へ戻る baseURLを書き換えたときにリバースプロキシの設定も書き換える必要があった。 nginx.conf events {} http { server { listen 80; server_name localhost; location /app/ { proxy_pass http://host.docker.internal:3000/app/; # ここを変更 } } } http://localhost/app にアクセスすると、ちゃんとサイトが表示されました。 今度こそ解決!! ٩(ˊωˋ*)و 別解 proxy_passを設定するときには、trailing slash(後ろに付けるスラッシュ)に気をつける必要がある。 詳しくはこちら↓の解説記事を参照。 https://www.xmisao.com/2014/05/09/nginx-proxy-pass.html trailing slashを付けずにproxy_passを設定すると、飛び先のURLには、locationの文字列も付与されるようになる。 これを利用して、最後のnginx.confの書き換えを以下のようにしてもOK nginx.conf events {} http { server { listen 80; server_name localhost; location /app/ { # proxy_pass http://host.docker.internal:3000/app/; proxy_pass http://host.docker.internal:3000; # これでもOK } } }
  • このエントリーをはてなブックマークに追加
  • Qiitaで続きを読む