- 投稿日:2020-06-25T23:36:36+09:00
Typechoインストール(Docker)
Typechoインストール(Docker)
インストール環境
Linux(CentOS 7.7)
Docker
※docker-composerがインストール済み
docker-networkが作成済みインストール手順
1、ディレクトリを作成
mkdir -p /home/typecho/data mkdir -p /home/typecho/mysql2、typechoディレクトリに入って,Docker-compose.ymlファイルを作成し、下記の内容を記入する。
version: "3" services: typecho: container_name: typecho restart: always image: 80x86/typecho:latest ports: - 8002:80 #ポート8002は適当に変更する。 volumes: - /home/typecho/data:/data - /home/typecho/mysql:/var/lib/mysql networks: default: external: name: docker-network #网络名根据实际情况填写3、コンテナーの生成して起動する。
docker-compose up -d
4、Mysqlのインストール
docker exec -it typecho sh #コンテナーに入る apk add mysql mysql-client #Mysql(MariaDB)をインストール mysql_install_db --user=mysql --datadir=/var/lib/mysql #Mysqlを初期化 mysqld_safe & mysql_secure_installation #パスワード設定後、全部「y」を選択して設定する。 mysql -u root -p #DBログイン create database typecho; #データベース作成5、Nginxにプロキシ設定が必要であれば、下記の内容をNginxの設定ファイルに設定する。
location / { proxy_pass http://typecho; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $http_host; }6、下記のURLをウェブブラウザに入力してTypechoの設定画面に遷移する。
- 投稿日:2020-06-25T22:44:51+09:00
docker : Data Volumeの作成から削除まで
Data Volumeとは
Dockerにおいてデータの永続化は気にしなかればならない問題です。
そこで使われるのが、Data Volumeです。Data VolumeはDockerコンテナ-ホスト間で直接ディレクトリを共有することで、データ永続化を実現する仕組みです。Data Volumeはコンテナを破棄してもホスト側に保持されることになります。コンテナのデータ永続化手法としては、Data Volumeコンテナの手法が推奨されています。
こちらでは、コンテナ間でディレクトリを共有することになります。Data Volumeコンテナは、データのみを保持するためのコンテナで、ホスト側に保持された永続化データの一部をVolumeとして別のコンテナに共有できるようにしたものです。Data VolumeコンテナのVolumeは、ホスト側の
/var/lib/docker/volumes/
(管理領域)以下に配置されます。ボリューム作成
$ docker volume create --name <VOLUME NAME>一覧表示
$ docker volume ls DRIVER VOLUME NAME local 0a990e22051c0815c18cb10ae5eea84ce37db2e91e83c3e976d54646c466c249 ...<omitted>... local mysql-dataマウント
$ docker run [options] -v {Host directory}:{Container directory} <Repository>[:tag] [Command] [Arguments] # 例) $ docker run -d --name mysql -p 3306:3306 -v mysql_data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=password mysql削除
$ docker volume rm <VOLUME NAME>全て削除
$ docker volume rm $(docker volume ls -qf dangling=true)リンク切れのみ削除
$ docker volume ls -qf dangling=true | xargs -r docker volume rm
[Command A] | xargs [Command B]
: コマンドAの実行結果を引数にしてコマンドBを実行-r
option : 標準入力(引き数)が空の場合はコマンドBを実行しないデータのエクスポート
Data Volumeコンテナで利用しているデータを他のコンテナで利用したい場合、一度データをエクスポートしたいとなるはずです。
Volumeデータをホスト側にエクスポートする方法を記載します。$ docker container run -v $PWD:/tmp \ --volumes-from mysql-data \ busybox \ tar cvzf /tmp/mysql-backup.tar.gz /var/lib/mysql上記例では、以下のようなイメージです。
- mysql-data(Data volumeコンテナ)の
/var/lib/mysql
の中身をtar圧縮- 圧縮したファイルをbusyboxコンテナの
/tmp
以下にmysql-backup.tar.gz
として保存- busyboxコンテナの
/tmp
をHost側のカレントディレクトリにマウント
- 投稿日:2020-06-25T22:36:59+09:00
Docker TypeScript で React 環境を構築
自分用のmemoのつもりで
Dockerで環境構築
Dockerはinstall済み■Dockerfile作成
空のPJディレクトリ内にDokerfile作成し以下を記載FROM node:13.5.0-alpine3.11 WORKDIR /usr/src/appFROMは新しいイメージの元となるイメージの読み込み
alpineというのでめちゃくちゃファイルサイズを小さくできるらしい■docker-compose.yml作成
※ymlは「yaml ain't markup language」の略で構造化データの表現方法
※簡単に言えば設定ファイルversion: '3' services: sample: build: context: . tty: true environment: - NODE_ENV=production volumes: - ./:/usr/src/app command: sh -c "cd tips && yarn start" ports: - "3000:3000"■イメージをビルド
docker-compose build■React と create-react-app をインストール + アプリ作成
docker-compose run --rm sample sh -c 'npx create-react-app sample_app --template typescript'出来上がるディレクトリ 構成
- Dockerfile - docker-compose.yml - アプリ名 |- node_module |- public |- src■起動
docker-compose up -d※ローカルでyarn startする時よりも時間がかかる感覚はある
Localhost:3000でApp.jsの中身が表示される
■停止
docker-compose stop
- 投稿日:2020-06-25T20:53:19+09:00
Node (Express + TypeScript) を Docker Image で起動するときの Tips
対応実施前
- express + typescript の hello world アプリを用意し、official の node image を利用した場合の image サイズ
REPOSITORY TAG IMAGE ID CREATED SIZE test-node-app-before latest 620fd8e74f42 3 seconds ago 1.32GB
- package.json
"scripts": { "start": "cross-env NODE_ENV=production ts-node --transpile-only src/server.ts",
- Dockerfile
- ts-node にて起動
- official の node image を利用
FROM node:12.18.1 WORKDIR /app ENV JWT_SECRET="dummy" PORT="80" COPY package.json /app COPY src /app/src RUN cd /app && npm install CMD ["npm","start"]対応内容
tsc コマンドで trance compile
- package.json の build に
tsc
を追加"scripts": { "build": "tsc",tsconfig.json の target / module を書き換え
JavaScriptにはいくつかのモジュールパターン(CommonJSやAMD、ECMAScriptなど)がある。TypeScriptをJavaScriptに変換する際、どのモジュールパターンにするかをmoduleに指定する必要がある。 moduleには'none', 'commonjs', 'amd', 'system', 'umd', 'es6', 'es2015', 'esnext'などを指定できる。デフォルトはtarget === "es3" or "es5" ? "commonjs" : "es6"、つまりtargetがes3かes5ならcommonjsとなる。
- tsconfig.json の
target
とmodule
を以下に指定{ "compilerOptions": { "sourceMap": true, "target": "es2017", "module": "commonjs",マルチステージビルドを実行 / apline linux を利用
- Dockerfile を以下のように編集
FROM node:12.18.1-alpine3.12 AS build WORKDIR /app COPY . /app RUN npm ci && npm run build FROM node:12.18.1-alpine3.12 WORKDIR /app ENV JWT_SECRET="dummy" PORT="80" COPY --from=build /app/dist /app/dist COPY package.json /app COPY package-lock.json /app RUN npm ci --production CMD ["npm","start"]
- Tips:
npm ci
コマンドを利用することで依存パッケージのダウンロードとインストールの高速化が実現できるdevDependencies に移動できるパッケージがないか確認する
- 以下が dependencies に記載されていたので修正
"jest": "^26.0.1", "ts-jest": "^26.1.0", "ts-node": "^8.10.2", "tslint-config-airbnb": "^5.11.2", "typescript": "^3.9.5"結果
- 101MB まで image の容量を削減することができた
docker images REPOSITORY TAG IMAGEID CREATED SIZE test-node-app latest 9cdb52f0f5cf 2 hours ago 101MB
- 投稿日:2020-06-25T19:17:37+09:00
100日後にエンジニアになるキミ - 97日目 - 開発環境 - Docker について3
昨日までのはこちら
100日後にエンジニアになるキミ - 95日目 - 開発環境 - Docker について
100日後にエンジニアになるキミ - 94日目 - 開発環境 - 仮想化について
100日後にエンジニアになるキミ - 91日目 - 運用 - 監視について
100日後にエンジニアになるキミ - 90日目 - 開発 - CIについて
100日後にエンジニアになるキミ - 88日目 - データ - データ転送について
100日後にエンジニアになるキミ - 86日目 - データベース - Hadoopについて
100日後にエンジニアになるキミ - 76日目 - プログラミング - 機械学習について
100日後にエンジニアになるキミ - 70日目 - プログラミング - スクレイピングについて
100日後にエンジニアになるキミ - 66日目 - プログラミング - 自然言語処理について
100日後にエンジニアになるキミ - 63日目 - プログラミング - 確率について1
100日後にエンジニアになるキミ - 59日目 - プログラミング - アルゴリズムについて
100日後にエンジニアになるキミ - 53日目 - Git - Gitについて
100日後にエンジニアになるキミ - 42日目 - クラウド - クラウドサービスについて
100日後にエンジニアになるキミ - 36日目 - データベース - データベースについて
100日後にエンジニアになるキミ - 24日目 - Python - Python言語の基礎1
100日後にエンジニアになるキミ - 18日目 - Javascript - JavaScriptの基礎1
100日後にエンジニアになるキミ - 14日目 - CSS - CSSの基礎1
100日後にエンジニアになるキミ - 6日目 - HTML - HTMLの基礎1
本日も
Docker
の続きです。Dockerの用語について
ざっくりとした導入をやりましたが、用語が多いので
おさらいをしておきましょう。Dockerfile
Dockerイメージをビルドする方法の手順が含まれるテキストファイルです。
これはバッチスクリプトに似ていて必要なプログラムのインストールや
ファイルのコピーなどが目的環境になるまで続きます。Dockerfileはアプリケーションの構成と
必要なリソースの詳細を記載します。イメージ(Docker Image)
コンテナーを作成するために必要なすべての依存関係と
情報を含むパッケージでDockerfileを介して作成されます。Dockerイメージはアプリケーションのスナップショットであり
すべての依存関係 (フレームワークなど) に加えて
コンテナーランタイムによって使用される全ての実行構成が含まれています。イメージは
Docker Hub
などで共有することができ
Dockerイメージの取得はdocker pull
コマンドで行います。取得したイメージの確認は
docker images
コマンドで行います。ビルド
Dockerfileの情報に基づいてイメージを作成します。
docker build
コマンドでビルドを行います。docker buildコマンドではDockerfileを元にしたコンテナーの起動構成
Dockerイメージの作成までを実行します。Run
docker run
コマンドはイメージを利用して
コンテナを起動状態で作成します。コンテナ(Docker Container)
Dockerイメージのインスタンスです。
コンテナーは、単一のアプリケーション、プロセス、またはサービスの実行を表します。
Dockerイメージのコンテンツ、実行環境、および標準的な命令セットで構成されます。サービスを拡張する場合は、同じイメージから複数のインスタンスを作成したり
バッチジョブで同じイメージから複数のコンテナーを作成し
各インスタンスにそれぞれ異なるパラメーターを渡したりします。コンテナの起動は
docker start
コマンドで行います。
起動はdocker ps -a
で確認ができます。
コンテナの停止はdocker stop
コマンドで行うことができます。Create
コンテナを停止状態で作成するには
docker create
を使用します。タグ
イメージにはタグ付することができます。
タグ付はdocker tag
コマンドで行います。Docker Engine
Dockerイメージ作成やコンテナ起動などを行うDockerのコアコンポーネントです。
Dockerの核となる機能部分です。コンポーネント
DockerではDocker Engineを中心に複数のコンポーネント単位で機能が開発されています。
必要に応じて複数のコンポーネントを組み合わせて使用します。Docker Compose
複数コンテナを一元管理するコンポーネントのことです。
レジストリ(Docker Registry)
Dockerイメージを公開・共有するコンポーネントのことです。
ほとんどのパブリックイメージの既定のレジストリは
Docker Hub
です
企業では自社用のイメージを管理するためのプライベートレジストリを持っています。Dockerコマンド
Dockerでのコマンドのまとめです。
イメージのダウンロード
docker pull [オプション] イメージ名[:タグ名]
イメージの一覧表示
docker images [オプション名] [リポジトリ名]
イメージの詳細確認
docker inspect [オプション] コンテナ識別子またはイメージ識別子 [コンテナ識別子またはイメージ識別
イメージのタグ設定
docker tag イメージ名:[タグ名] ユーザー名/イメージ名:[タグ名]
イメージの検索
docker search [オプション] 検索キーワード
イメージの削除
docker rmi [オプション] イメージ名 [イメージ名]
Docker Hubへのログイン
docker login [オプション] [サーバ名]
イメージのアップロード
docker push イメージ名[:タグ名]
Docker Hubからのログアウト
docker logout [サーバ名]
コンテナの生成/起動
docker run [オプション] イメージ名[:タグ名] [引数]
コンテナのバックグラウンド実行
docker run [オプション] イメージ名[:タグ名] [引数]
コンテナのネットワーク設定
docker run [オプション] イメージ名[:タグ名] [引数]
リソースを指定してコンテナを生成/実行
docker run [リソースオプション] イメージ名[:タグ名] [引数]
コンテナを生成/起動する環境を指定
docker run [環境設定オプション] イメージ名[:タグ名] [引数]
稼働コンテナの一覧表示
docker ps [オプション]
コンテナの稼働確認
docker stats [コンテナ識別子]
コンテナの起動
docker start [オプション] コンテナ識別子 [コンテナ識別子]
コンテナの停止
docker stop [オプション] コンテナ識別子 [コンテナ識別子]
コンテナの再起動
docker restart [オプション] コンテナ識別子 [コンテナ識別子]
コンテナの削除
docker rm [オプション] コンテナ識別子 [コンテナ識別子]
コンテナの中断/再開
docker pause コンテナ識別子 [コンテナ識別子]
稼働コンテナへの接続
docker attach コンテナ識別子
稼働コンテナでプロセス実行
docker exec [オプション] コンテナ識別子 実行するコマンド [引数]
稼働コンテナのプロセス確認
docker top コンテナ識別子
稼働コンテナのポート転送確認
docker port コンテナ識別子
コンテナの名前変更
docker rename コンテナ識別子 コンテナ識別子
コンテナ内のファイルをコピー
docker cp コンテナ識別子:コンテナ内のファイルパス ホストのディレクトリパス
docker cp ホストのファイル コンテナ識別子:コンテナ内のファイルパス
コンテナ操作の差分確認
docker diff コンテナ識別子
Dockerのバージョン確認
docker version
Dockerの実行環境確認
docker info
コンテナからイメージ作成
docker commit [オプション] コンテナ識別子 [イメージ名[:タグ名]]
コンテナをtarファイル出力
docker export コンテナ識別子
tarファイルからイメージ作成
docker import ファイルまたはURL - [イメージ名[:タグ名]]
イメージの保存
docker save [オプション] 保存ファイル名 [イメージ名]
イメージの読み込み
docker load [オプション]
DockerfileからDockerイメージの作成
docker build -t [生成するイメージ名]:[タグ名] [Dockerfileの場所]
忘備録的に書いたので間違ってたらすいません。
まとめ
Dockerではかなりやれること、用語も多いので
何がなんなのかを把握しておくと良いと思います。そのためのコマンドもたくさん有るので
すこしづつ使っていきながら覚えていきましょう。君がエンジニアになるまであと03日
作者の情報
乙pyのHP:
http://www.otupy.net/Youtube:
https://www.youtube.com/channel/UCaT7xpeq8n1G_HcJKKSOXMwTwitter:
https://twitter.com/otupython
- 投稿日:2020-06-25T18:16:14+09:00
CronをDocker上で動かす
概要
- バージョン: Ruby 2.6.5 Rails 5.2.4
- 開発環境: Docker/docker-compose
実現したいこと
- cronを使ってRailsのバッチ処理を実現したい
- Docker環境で動かしたい
BusyBoxの利用がお勧め
元々、Wheneverを使って設定したcronをDocker上で動かそうとしていました。
Docker環境だとcronが動かないようなので、色々な記事を参考にし各種ファイルの設定を行いました。
しかし、cronが動かない。Dockerコンテナに入りエラーログを調べ、対応しても上手くいきませんでした。
ちなみに、エラーログとその対応は以下になります。
log/crontab.logbundler: failed to load command: bin/rails (bin/rails)log/crontab_error.logActiveRecord::AdapterNotSpecified: 'production' database is not configured. Available: ["default", "development", "test"]以下の記事を参考にし、
https://www.cotegg.com/blog/?p=1606
schedule.rbに環境変数を渡す記述をしたり、database.ymlにproductionデータベースを構成する記述を追記したりしました。cronの再起動を行い、再びlogファイルを確認しましたが、再度同じエラーが吐かれてしまいました。
恐らく、環境変数を上手く渡せていなかったり、Docker 上でのcron の実行環境が、うまく開発環境と認識されていないことが原因だったのではないかと思います。
私の場合は、結局Wheneverを使って設定したcronをDocker上で動かすことができませんでした。
そこで、この問題が比較的簡単に解決してくれたのが、
BusyBoxという方法です。BubyBoxのメリット
以下のDocker上でcronを使用する際の課題を解決し、シンプルに定期実行をしてくれます。
- cronで実行するプログラムにコンテナに設定した環境変数を渡したい。
- cronは環境変数が独立している
- いちいちファイルに書き出し、読み込みが必要
- ログが標準出力・標準エラー出力されない
BusyBoxのインストール(Debian系)
※AlpineLinuxの場合、crondで使えるようです
apt-get install -y busybox-static
ディレクトリ構成
.
|- Dockerfile
|- crontab
|- docker-compose.yml
|- main.shDockerfile
DockerfileFROM ruby:2.6.5 # インストール RUN apt-get update && apt-get install -y \busybox-static \ # タイムゾーン設定 ENV TZ=Asia/Tokyo # mai.shファイルをコピー COPY ./main.sh /myapp CMD ["busybox", "crond", "-l", "8", "-L", "/dev/stderr", "-f"]crontab
テスト用に1分毎に実行します
* * * * * /app/main.shdocker-compose.yml
crontabファイルをマウントすることで、外部から実行時間を指定できるようになります。
docker-compose.ymlversion: '3' services: busybox: build: . volumes: - ./crontab:/var/spool/cron/crontabs/rootmain.sh
権限エラーを防ぐために、ターミナル上で以下を実行します。
chmod +x main.shテストとして、Dateを出力します。
main.shdate
実行
docker-composeで実行する場合
docker-compose build # Dockerイメージをビルド docker-compose up -d # docker-compose.ymlの変更を反映させる docker-compose logs -f # ログ出力1分毎に、dateを出力できました!
参考にした記事
- 投稿日:2020-06-25T13:44:23+09:00
Can't open /home/laradock/.nvm/nvm.sh がでたとき
/etc/hosts に以下を追記
(具体的なIPアドレスはhttps://githubusercontent.com.ipaddress.com/raw.githubusercontent.com ここで調べられる)199.232.68.133 raw.githubusercontent.com
Windowsユーザの場合は、ローカルにあるhostsファイルも編集が必要
C:\Windows\System32\drivers\etc\hosts
- 投稿日:2020-06-25T13:41:10+09:00
Windows 10 ProにDocker Desktop (+ Kubernetes) をインストールする
対応するDockerのバージョン
- Docker Desktop 2.0.0.0-win81
下記の手順は最新のインストール手順とは異なっている可能性があります。
Docker Desktop for Windowsのシステム要件
Docker Desktop for Windowsは、Microsoftの仮想化テクノロジーであるHyper-Vを利用します。
そのためWindows Homeエディションや古いバージョンのWindowsはサポートされません。Docker公式ページに提示されているDocker for Windowsのシステム要件は次の通りです。
- Windows 10 64bit版のPro、EnterpriseまたはEducation(1607 Anniversary Update, Build 14393またはそれ以降)であること
- BIOS設定で仮想化テクノロジーが有効になっていること
- CPUがSLAT(メモリ管理の仮想化)をサポートしていること
- 少なくとも4GBのメモリーが利用できること
Hyper-Vを有効にすると、VirtualBoxなど他の仮想化テクノロジーを利用するアプリケーションが利用できなくなります。導入には十分注意してください。
なお、システム要件を満たさないWindowsでKubernetesを試したい場合には、Minikubeを利用する方法もあります。Minikubeは、Hyper-Vの他にVirtualBoxをサポートしています。詳細については次のURLを参照してください。
https://kubernetes.io/docs/tasks/tools/install-minikube/
インストール手順
(1) Docker Hubからダウンロードしたインストールイメージ(
Docker Desktop Installer.exe
)をダブルクリックします。(2) "ユーザーアカウント制御"のダイアログが表示されるので[はい]ボタンをクリックします。
(3) "Configuration"画面で[Ok]ボタンをクリックします。
(4) インストールが成功すると"Installation succeeded"と表示されるので[Close and log out]ボタンをクリックします。この際、Windowsのデスクトップから自動的にサインアウトするので、あらかじめ起動中のアプリケーションを終了しておいてください。
(5) 再度デスクトップにサインインします。Hyper-Vが有効になっていない場合には、次のダイアログが表示されるので[Ok]ボタンをクリックしてコンピューターを再起動します。
(6) 再起動後、デスクトップにサインインするとログインダイアログが表示されます。
(7) 事前に登録したDocker IDでログインします。
(8) インジケーターのDockerのアイコンの点滅が終わるまでしばらく待ちます。
Kubernetesの有効化(必要に応じて)
以下の手順は、Docker内にKubernetesの環境を作りたい場合のみ実行してください。
(1) 点滅が終わったら、タスクバーのDockerのアイコンのをクリックし[Settings]を選択します。
(2) "Kubernetes"タブに移動し、[Enable Kubernetes]にチェックを入れ[Apply]ボタンをクリックします。(インストールが完了するまでしばらく時間がかかります)
- 投稿日:2020-06-25T12:01:05+09:00
コンテナのデプロイ自動化
はじめに
この記事では、「マイクロサービス」、「コンテナ」、「CI/CD」について初歩的な知識をまとめました。
いわゆるDXで実現したいこと、解決したい課題や目的は、企業によって様々あるかと思いますが、「マイクロサービス」、「コンテナ」、「CI/CD」といった技術を使うことで、「ビジネス追従スピードの強化」が実現できます。
コロナ影響を受ける、昨今よく言われることですが、変化の激しいビジネスの世界では柔軟な機能拡張が要求され、これを満たすようなアーキテクチャが求められています。従来のモノリスな設計思想ではなく、コンテナという技術の普及と共に、マイクロサービスという設計が注目されています。
またアジャイル開発や、DevOpsは、もう10年以上前から提唱されている、開発スピードをアップや生産性アップが期待できる開発手法ですが、コンテナ技術の普及に伴い、さらに進化しています。前半で、「マイクロサービス」、「コンテナ」、「CI/CD」について簡単に説明し、後半でコンテナをAWS環境に自動デプロイする手法を記載しました。マイクロサービス
まず一つ目のキーワード、「マイクロサービス」についてです。
モノリシックなシステムを、マイクロサービス化するとは、アプリケーションを機能単位で分散させ、疎結合化することです。そして分散させたアプリケーション間はAPIで連携します。その効果としては、開発範囲を限定できるので、俊敏な機能追加が可能です。またチームビルディングの面でも、開発チームの小規模化や、下部組織へシステム管理権限を委譲できるといった効果が期待できます。中央集権型組織ではなく、末端のチームや個人が、俊敏に判断し、自律的に動く組織を目指す場合に、フィットします。
一方、マイクロサービス化の課題として、設計・実装の難易度アップによる、人材コストや学習コストの増加が挙げられます。その他、権限委譲を進めたことにより、分散されたシステムや管理するチームの統制が効かなくなる点も課題として想定され、横断的な部署による支援、管理が必要になります。
マイクロサービス化を検討する際は、どの機能を分散させ権限委譲するかを考慮する必要があります。組織が大きくなってきて、より俊敏に動ける自律的な組織を目指したいという目的もなく、小さな組織が、ただ流行りのアーキテクチャだから採用しようという場合は、メリットデメリットを挙げて検討した方が良いかもしれません。コンテナ
上記のマイクロサービスを実現する技術として、コンテナがあります。コンテナといえばDockerが主流です。
コンテナ登場以前は、仮想マシン(OS)単位でアプリケーションを配置させるやり方でしたが、コンテナを使うと、OS上のDocker上に、コンテナ(アプリケーション)を配置することが可能です。
これにより、環境の構築が圧倒的に楽になります。従来の仮想マシンごとの環境差分はDockerが吸収してくれます。複数拠点に、同じシステムを展開する場合、以前は、各拠点の環境差分に悩まされ、構築作業が大変でしたが、仮想マシンにDockerさえインストールできれば、そのような環境差分に悩まされることはありません。またエンジニアが開発スタート時に行う、開発環境の構築も同様に楽になります。開発環境だけ、Docker使って、本番環境は従来通りというやり方も、多いのが実情なのかもしれません。Dockerのコマンド
Dockerの基本的なコマンドです。
Dockerイメージの取得
docker pull “123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image”"123456789012.dkr.ecr.ap-northeast-1.amazonaws.com"がホスト名で、"nginx-image"がリポジトリ名です。
Dockerイメージ一覧を表示
doker images REPOSITORY TAG IMAGE ID CREATED SIZE 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image latest 4fe1b0c04855 2 months ago 127MBコンテナの作成
docker run --name nginx-app -d -p 8080:80 " 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image:latest" 1dfa0db0ed80eabe6e377481a6be25e967da78230bfb0f47c627f0742d965442コンテナの一覧表示
docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 1dfa0db0ed80 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image:latest "nginx -g 'daemon of…" 3 minutes ago Up 3 minutes 0.0.0.0:8080->80/tcp nginx-appDockerイメージの作成(ビルド)
docker build -t 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image:latestDockerイメージのリポジトリへのPush
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image:latestCI/CD
CI/CDとは、DevOpsの中の一つの手法で、継続的インテグレーション(continuous integration)、継続的デリバリー(continuous delivery)のことを指します。システム運用後、頻繁に発生する仕様変更に対応できるよう、継続的に改修⇒結合テスト⇒デプロイメントすることをCI/CDといいます。以下のようなCI/CDパイプラインと呼ばれるパイプラインに例えられます。
最近では継続的Deploymentや、No-Deploymentという言葉も耳にするようになりました。CI/CDツールは色々ありますが、今回はCircleCIというツールを使ってみました。以下に、DockerコンテナのAWS環境に自動デプロイするまでを示しました。Gitを使って、修正コードをPushし、AWSのECS(Elastic Container Service)にデプロイするまでの流れです。実際の環境構築は以下のサイトが詳しいです。
CircleCI Orbsで ECR/ECS にデプロイ
1. git push
開発者がソースコードを修正してgitでpushすると、そのpushを検知し、CirCleCIに連携されます。gitでのpush操作以降の、コンテナ起動までをCircleCIが自動で実行してくれます。
2. test
CirCleCIで、テストコードによりテストを実行します。
3. build container image
設定した環境でコンテナのビルドが始まります。
4. push container image
出来上がったコンテナイメージをAWSのECR(Elastic Container Registry)に登録します。
5. deploy & register task definition and update service
AWSのECSでタスク定義を登録し、サービスを更新します。
6. start container
更新されたサービスに従い、EC2またはFargate上でコンテナが起動します。
以下、Circleciの設定ファイル.circleci/config.ymlの記述です。コンテナのビルドとイメージのPushを記載しています。
config.ymlversion: 2.1 orbs: aws-ecr: circleci/aws-ecr@6.0.0 aws-ecs: circleci/aws-ecs@0.0.8 workflows: build_and_push_image: jobs: - aws-ecr/build-and-push-image: region: AWS_REGION account-url: AWS_ECR_ACCOUNT_URL repo: '${MY_APP_PREFIX}-sample' tag: "${CIRCLE_SHA1}" - aws-ecs/deploy-service-update: requires: - aws-ecr/build-and-push-image family: '${MY_APP_PREFIX}-task' cluster-name: '${MY_APP_PREFIX}-cluster' service-name: '${MY_APP_PREFIX}-service' container-image-name-updates: 'container=${MY_APP_PREFIX}-container,tag=${CIRCLE_SHA1}'おまけ
最後にデプロイメントについて調べてみました。
カナリアリリース
本番環境を全ユーザに対して、一斉にリリースするのではなく、一部のユーザに先行してリリースして、段階的に全ユーザに公開していく手法です。
Blue-Greenリリース
現行環境とは別に新環境を用意して、ユーザのアクセス先を切り替えていく手法。新環境で問題が発生した場合は、旧環境にユーザのアクセス先を戻します。リリース後問題がない場合は、旧環境を次の新環境として利用します。
- 投稿日:2020-06-25T09:29:14+09:00
VMware Playerが起動しなくなっちゃった。あの記事から1年後
はじめに
去年Windows上で、仮想マシンを起動しようとした時のこと、あるエラーが発生した.
それについての記事を上げるも、詳しい情報を返すことなく放置すること1年以上.
Dockerの勉強をしようとしたら、当然のようにまた同じエラーにぶつかった.今年は魔法のような修正方法が出てるのでそれを紹介します!!
ちなみにこれが、前回の記事
環境
- Windows10 Pro 1909 buid 1863...
- 後に、Windows10 Pro 2004 buid 1904...
- VMware Player 14
- 後に、VMware Player 15.5.5へ
- 仮想マシン(CentOS 6)
エラーの内容
VMware Player と Device/Credential Guard には互換性がありません。 VMware Player は Device/Credential Guard を無効にした後で実行することができます。 詳細については、http://www.vmware.com/go/turnoff_CG_DG を参照してください。
- VMwareで仮想マシンを起動するには Dvice/Credential Guard を無効にしなきゃいけないらしい
詳細についてのリンク先には英語でめっちゃかいてある.
日本語訳で対処されてる方々もいるけど、総じて新しいドライブか新規パーティションを作成しなきゃいけないらしい.
え、そんなんめっちゃやなんだけど.解決手段
米VMwareは5月28日(現地時間)、パーソナルデスクトップ向けの仮想化ソリューション「VMware Workstation 15.5.5」「VMware Workstation Player 15.5.5」をリリースした。本バージョンの目玉は、「Hyper-V」との共存が可能になったこと。
まじ!?
すぐに鵜呑みにするタイプなので、すぐに上記ソフトをインストールした
また、すぐには治らないやつ.
かとおもったら、なお、VBSが有効化されたホストで「VMware Workstation」「VMware Workstation Player」を利用するには、OSを「Windows 10 May 2020 Update(バージョン 2004)」へアップグレードする必要がある。また、CPU要件としてIntel製の場合“Sandy Bridge”もしくはそれ以降、AMD製の場合“Bulldozer”もしくはそれ以降のアーキテクチャーが指定されているので注意
そうなのね!
ということで、こちらもすぐにダウンロードしてこよう!!前回のアプデ同様に、順次インストールされるらしいけど、手動でやりたい!
Windows 10 May 2020 Update結構時間かかったけど、無事インストールが終わって再起動した!
Windowsの機能から、WSLやHyper-Vなどいままで使えなかった機能を全部チェック!!
再起動!!
VMware Player 15.5.5を起動して仮想マシンを起動してみたら、、
起動した!!
完了!!!あとがき?
VMware15.5.5は、microsoft社とvmwareが協力して作ったAPIを活用してるらしい.
DockerからUbuntsuも起動できたし、今のところ問題はなさそう.
VirtualBoxは試してないけど、記事曰く、今後もこのAPIへの準拠を促していくので、対応してないソフトも順次対応しだすのかなぁと.
にしても、使える環境を整えるだけでこんなめんどくさいのか…さすが開発最難関、環境整備だわ
- 投稿日:2020-06-25T01:58:59+09:00
docker + docker-compose + docker-syncでSymfonyの環境構築 (超初心者向け)
はじめに
Docker + Laravelの環境構築はQiitaに溢れているのですが、Docker + Symfonyの記事はあまり見当たらなかったので記事にしました。(と言ってもほぼLaravelと変わらないですが)。
Docker初心者なので、各種設定などを備忘録として細かく解説していこうと思います。構成
ホスト環境
ツール バージョン Mac macOS Catalina 10.15.5 docker-compose 1.25.5 docker-sync 0.5.14 構築環境 (ゴール)
- PHP 7.4
- mysql 5.7
- Apache
- Symfony 5
ディレクトリ構成
appディレクトリにsymfonyのソースコードを配置します。注意点としてルートにある
.env
はSymfonyの.env
とは異なります。project/ ├ app/ ├ docker/ │ ├ apache/ │ │ └ my_app.conf │ ├ php/ │ │ └ php.ini │ └ Dockerfile ├ .env ├ docker-compose.yaml └ docker-sync.yaml必要なツール類のインストール
Homebrewを使って、ホスト環境に必要なツール類をインストールします。
docker
$ brew install docker $ brew cask install dockerdocker-sync
>> ~/.zshrc
のところは環境に合わせて変えてください。$ brew install ruby $ echo 'export PATH="/usr/local/opt/ruby/bin:$PATH"' >> ~/.zshrc $ source ~/.zshrc $ gem install docker-sync -n /usr/local/bindocker-composeの設定
docker-compose.yamlversion: '3' services: app: container_name: my_app build: ./docker ports: - 8880:80 volumes: - my_app_symfony:/var/www/html - ./docker/php/php.ini:/usr/local/etc/php/php.ini - ./docker/apache/my_app.conf:/etc/apache2/sites-enabled/my_app.conf depends_on: - mysql mysql: image: mysql:5.7 container_name: my_app_app_mysql environment: MYSQL_ROOT_PASSWORD: $DB_ROOT_PASSWORD MYSQL_DATABASE: $DB_NAME TZ: 'Asia/Tokyo' command: mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci ports: - 3306:3306 volumes: my_app_symfony: external: true解説
docker-composeは複数のDockerコンテナをまとめて管理するツールです。
docker-compose.yaml
のservices
の下に各種コンテナの設定を記述します。
app
には、WEBサーバーとして動作するコンテナの設定を記述してあります。container_name
のmy_appは好きな値に書き換えて大丈夫です。
build: ./docker
と記述することでdocker/Dockerfileの内容にしたがってビルドを行います。
ports
にはコンテナで立ち上げたプロセスのどのポートをローカルのどのポートにバインドするかと言う設定を記述します。ローカル:コンテナの順で記述するので、今回はローカルの8880ポートをコンテナの80ポートへバインドする、と言う意味です。http://localhost:8880 へリクエストを送ると、コンテナ内の80ポートへリクエストが転送されます。
volumes
にはローカルにあるファイルやディレクトリをコンテナと同期する場合に記述します。volumes
の2,3行目はローカルのphp.iniとmy_app.confをコンテナと同期する設定が記述してあります。1行目は、appディレクトリにあるローカルのsymfonyのプロジェクトをコンテナの/var/www/html
と言うように記述してありますが、symfonyのソースコードは量が多く普通に同期するとパフォーマンスが落ちるので後述するdocker-syncを用いて同期を行います。ここでは、一番下に記述してあるvolumes
の項目で(docker-syncで作成された)外部のボリュームを定義し、それにmy_app_symfony
と言う名前をつけています。app
コンテナのvolumes
のローカルの方にはこのmy_app_symfony
を指定します。
mysql
にはDBとして使用するmysqlコンテナの設定が記述してあります。こちらはDockerfileを用いず、あらかじめ公開されているイメージを使用します。イメージはDockerhubなどで検索することができます。Dockerhubのmysqlのページにドキュメントがあるのですが、コンテナを作成する時に特定の環境変数を渡すことで各種設定を行うことができます。環境変数はenvironment
に書くことで渡すことができ、今回はMYSQL_ROOT_PASSWORD
、MYSQL_DATABASE
、TZ
の三つを使用していますです。役割は名前から推測できると思うので割愛します。また、このファイルに変数の値をベタがきしても良いのですが、今回は柔軟性を持たせるためにローカルの環境変数から値を取得してくるようにしています(ややこしい)。ルートディレクトリにある.env
ファイルに.envDB_ROOT_PASSWORD=root DB_NAME=app_dbと言うように書いておくことで、コンテナ作成時に
docker-compose.yaml
無いの変数を書き換えてくれます。
command
にはコンテナ作成時にコンテナ内で実行されるコマンドを記述することができます。/docker ディレクトリ
php.inimemory_limit = 2048M date.timezone = "Asia/Tokyo" mbstring.internal_encoding = "UTF-8" mbstring.language = "Japanese"my_app.conf<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html/my_app/public ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>DockerfileFROM php:7.4-apache RUN a2dissite 000-default WORKDIR /var/www/html RUN apt-get update && apt-get install -y git zip unzip RUN apt-get install -y wget libjpeg-dev libfreetype6-dev RUN apt-get install -y libmagick++-dev \ libmagickwand-dev \ libpq-dev \ libfreetype6-dev \ libjpeg62-turbo-dev \ libpng-dev \ libwebp-dev \ libxpm-dev RUN docker-php-ext-configure gd --with-freetype=/usr/include/ --with-jpeg=/usr/include/ RUN docker-php-ext-install -j$(nproc) gd RUN cd /usr/bin && curl -s http://getcomposer.org/installer | php && mv /usr/bin/composer.phar /usr/bin/composer解説
php.ini
とmy_app.conf
には特殊なことは書いていません。必要に応じて編集してください。
Dockerfile
にはコンテナをどのようにビルドするかと言う手順を記述します。
1行目のFROM
にはコンテナの元となるイメージを指定します(Dockerhubで検索)。RUN xxxx
とすると、コンテナ内でxxxx
を実行します。注意点として、RUN
コマンドで実行した結果は次のRUN
コマンドへは引き継がれませんので、cd
などでディレクトリ移動したのに何故かファイルが無い!!見たいなことが起こります。結果を引継ぎたい時は&&
でコマンドを続けて指定します。
2行目以降ではApacheのデフォルトサイトを無効化し、php
のgd拡張のインストール及び、composer
のインストールを行っています。WORKDIR /var/www/html
では作業ディレクトリを/var/www/html
に設定しています。docker-syncの設定
docker-sync.yamlversion: '2' syncs: my_app_symfony: src: './app' sync_host_ip: '127.0.0.1' sync_host_port: '5000' sync_strategy: 'native_osx' sync_excludes: ['.git', '.gitignore', 'node_modules']解説
syncs
の中に各種ボリュームの定義を記述します。my_app_symfony
のところはdocker-compose
のvolumes
で指定したボリューム名と一致させます。
src
には同期させるディレクトリを指定し、sync_host_ip
とsync_host_port
それぞれホストのIPトポートを指定します。sync_strategy
は、色々あるようですが、とりあえずnative_osx
で問題無いと思います(よくわかってない)。sync_excludes
には同期しないファイル、ディレクトリを指定します。node_modules
など量が多くPHPで使用しないソースコードなどは同期しない方が無難だと思います。起動
※ 8880ポート、8888ポート、5000ポート、3306ポートを使用するので、これらを使用しているソフトがある場合は停止しておいてください。
$ docker-sync start $ docker-compose up -d --buildこの時点で各種コンテナが起動します。
続いて、コンテナへ入り
composer
を用いてsymfonyのプロジェクトを作成します。コンテナからはexit
で抜けられます。# appコンテナでbashを実行 $ docker-compose exec app /bin/bash # コンテナ内 root@eb419aab1d32:/var/www/html# composer create-project symfony/skeleton my_appローカルのブラウザから http://localhost:8880 へアクセスするとsymfonyの画面が表示されていると思います!
各種操作
# コンテナの終了 $ docker-compose stop # コンテナの再開 $ docker-compose start # composer install $ docker-compose exec app composer install以上!