20200625のdockerに関する記事は11件です。

投稿日：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/mysql
2、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の設定画面に遷移する。

http://ip

　 Tweet
Qiitaで続きを読む

投稿日：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側のカレントディレクトリにマウント

　 Tweet
Qiitaで続きを読む

投稿日：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/app
FROMは新しいイメージの元となるイメージの読み込み
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

　 Tweet
Qiitaで続きを読む

投稿日：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 を書き換え

tsconfigのmoduleとtargetには何を設定すればいいか - TypeScript

以下抜粋
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 コマンドを利用することで依存パッケージのダウンロードとインストールの高速化が実現できる

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"
参考サイト

【いまさらですが】package.jsonのdependenciesとdevDependencies

結果

101MB まで image の容量を削減することができた
docker images
REPOSITORY     TAG     IMAGEID       CREATED      SIZE
test-node-app  latest  9cdb52f0f5cf  2 hours ago  101MB

　 Tweet
Qiitaで続きを読む

投稿日：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_HcJKKSOXMw

Twitter：
https://twitter.com/otupython

　 Tweet
Qiitaで続きを読む

投稿日：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.log
bundler: failed to load command: bin/rails (bin/rails)
log/crontab_error.log
ActiveRecord::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.sh

Dockerfile
Dockerfile
FROM 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.sh
docker-compose.yml

crontabファイルをマウントすることで、外部から実行時間を指定できるようになります。
docker-compose.yml
version: '3'

services:
  busybox:
    build: .
    volumes:
      - ./crontab:/var/spool/cron/crontabs/root
main.sh

権限エラーを防ぐために、ターミナル上で以下を実行します。
chmod +x main.sh
テストとして、Dateを出力します。
main.sh
date
実行

docker-composeで実行する場合
docker-compose build   # Dockerイメージをビルド
docker-compose up -d   # docker-compose.ymlの変更を反映させる
docker-compose logs -f # ログ出力
1分毎に、dateを出力できました！

参考にした記事

https://shimoju.org/2017/10/09/busybox-crond/

https://ngyuki.hatenablog.com/entry/2017/04/18/195254

https://qiita.com/nanamen/items/5c4ef45e2ee84bafdd1d

https://ja.stackoverflow.com/questions/67124/docker-compose-yml%E3%81%A7cron%E3%82%92%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%9F%E3%81%84

　 Tweet
Qiitaで続きを読む

投稿日：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

　 Tweet
Qiitaで続きを読む

投稿日：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]ボタンをクリックします。（インストールが完了するまでしばらく時間がかかります）

　 Tweet
Qiitaで続きを読む

投稿日：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-app
Dockerイメージの作成(ビルド)
docker build -t 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image:latest
DockerイメージのリポジトリへのPush
docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/nginx-image:latest
CI/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.yml
version: 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リリース

現行環境とは別に新環境を用意して、ユーザのアクセス先を切り替えていく手法。新環境で問題が発生した場合は、旧環境にユーザのアクセス先を戻します。リリース後問題がない場合は、旧環境を次の新環境として利用します。

　 Tweet
Qiitaで続きを読む

投稿日：2020-06-25T09:29:14+09:00

VMware Playerが起動しなくなっちゃった。あの記事から1年後

はじめに

去年Windows上で、仮想マシンを起動しようとした時のこと、あるエラーが発生した.
それについての記事を上げるも、詳しい情報を返すことなく放置すること１年以上.
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 Player 15.5.5

米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への準拠を促していくので、対応してないソフトも順次対応しだすのかなぁと.

にしても、使える環境を整えるだけでこんなめんどくさいのか…さすが開発最難関、環境整備だわ

　 Tweet
Qiitaで続きを読む

投稿日：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 docker
docker-sync

>> ~/.zshrcのところは環境に合わせて変えてください。
$ brew install ruby
$ echo 'export PATH="/usr/local/opt/ruby/bin:$PATH"' >> ~/.zshrc
$ source ~/.zshrc
$ gem install docker-sync -n /usr/local/bin 
docker-composeの設定
docker-compose.yaml
version: '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ファイルに
.env
DB_ROOT_PASSWORD=root
DB_NAME=app_db
と言うように書いておくことで、コンテナ作成時にdocker-compose.yaml無いの変数を書き換えてくれます。
commandにはコンテナ作成時にコンテナ内で実行されるコマンドを記述することができます。

/docker ディレクトリ
php.ini
memory_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>
Dockerfile
FROM 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.yaml
version: '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
以上！

ツール	バージョン
Mac macOS	Catalina 10.15.5
docker-compose	1.25.5
docker-sync	0.5.14

　 Tweet
Qiitaで続きを読む

20200625のdockerに関する記事は11件です。

Typechoインストール（Docker）

Typechoインストール（Docker）

docker : Data Volumeの作成から削除まで

Data Volumeとは

ボリューム作成

一覧表示

マウント

削除

全て削除

リンク切れのみ削除

データのエクスポート

Docker TypeScript で React 環境を構築

Node (Express + TypeScript) を Docker Image で起動するときの Tips

対応実施前

対応内容

tsc コマンドで trance compile

tsconfig.json の target / module を書き換え

マルチステージビルドを実行 / apline linux を利用

devDependencies に移動できるパッケージがないか確認する

結果

100日後にエンジニアになるキミ - 97日目 - 開発環境 - Docker について3

Dockerの用語について

Dockerfile

イメージ(Docker Image)

ビルド

Run

コンテナ(Docker Container)

Create

タグ

Docker Engine

コンポーネント

Docker Compose

レジストリ(Docker Registry)

Dockerコマンド

イメージのダウンロード

イメージの一覧表示

イメージの詳細確認

イメージのタグ設定

イメージの検索

イメージの削除

Docker Hubへのログイン

イメージのアップロード

Docker Hubからのログアウト

コンテナの生成/起動

コンテナのバックグラウンド実行

コンテナのネットワーク設定

リソースを指定してコンテナを生成/実行

コンテナを生成/起動する環境を指定

稼働コンテナの一覧表示

コンテナの稼働確認

コンテナの起動

コンテナの停止

コンテナの再起動

コンテナの削除

コンテナの中断/再開

稼働コンテナへの接続

稼働コンテナでプロセス実行

稼働コンテナのプロセス確認

稼働コンテナのポート転送確認

コンテナの名前変更

コンテナ内のファイルをコピー

コンテナ操作の差分確認

Dockerのバージョン確認

Dockerの実行環境確認

コンテナからイメージ作成

コンテナをtarファイル出力

tarファイルからイメージ作成

イメージの保存

イメージの読み込み

DockerfileからDockerイメージの作成

まとめ

作者の情報

CronをDocker上で動かす

概要

実現したいこと

BusyBoxの利用がお勧め

BubyBoxのメリット

BusyBoxのインストール(Debian系)

ディレクトリ構成

Docker TypeScript で　React 環境を構築

Can't open /home/laradock/.nvm/nvm.sh　がでたとき