学習ナレッジ＃１知識習得を楽しめるプロを目標に「WindowsでAWSクラウドを意識したLinux/Docker学習」
まえがき・諸注意
本ナレッジは外部サイトのリンクを記載しています。
各リンク先のウェブサイトの内容は更新・変更により本ナレッジ作成時点とは異なる場合があります。
なお、英語のウェブサイトも含まれます。
もし英語が苦手であっても読み解く力をつけましょう。
私の経験上、日本語よりも英語のサイトの方が情報量がかなり豊富です。
自己紹介（軽め）
2022年末からメンターを始めましたおとはです。
メンター歴の少ない私のことを少しでも知って頂こうかと思い、ナレッジを使って私の学習の手法や考え方などを紹介させて頂きます。
なお、プロフィールのスキル欄の通りDockerは全くの未経験です。（この記事作成時点で４日目）
細かなプロフィールは こちら からご覧ください。
Docker（コンテナ）を学習するきっかけ
正直言いますとそこまで必要性は感じていないです。
2022年時点で世界でのコンテナ使用率は36%で、国内は2021年情報で本番環境で2割弱という情報があります。
仕事はＩＴ業界ですがウェブが主体ではありません。
私の場合はインフラ・ウェブアプリは個人１０年以上、仕事３年程度です。
そのため個人趣味で得た知識を本業へ生かしているような感じです。
なぜ、このタイミングでDockerを覚えようかと思ったか。
大きな理由はAWSのクラウドサービスを本格的に使い始めたから。
特にAWS Fargateのお値段が高いイメージがあるが運用が楽になるのであれば試してみたいと思ったからです。
情報収集の仕方と書籍について
日本語のブログサイト -> 英語のブログサイト -> 本家のサイト（大体英語）の順に調べて学習しています。
この方法で欲しい情報の多くは得られるので費用をあまり掛けたくない方向けの玄人志向です。
私は書籍購入にほぼほぼ投資をしないまま１０年以上やってきました。
ですので、紹介できる書籍はございません、ご了承ください。
ちなみに書籍の方が自分が求めている情報以外の付加情報が得られることがあります。
本を読むのが好きな方であればおすすめしますが、経験しないと身につかないです。
手を動かして理解して、上手くできない時は悩んで・調べて・解決しての繰り返しが重要です。
インターネットを使って様々な情報が得られる便利な時代です。
特に昨今は講師・メンターさんがいて気軽に相談しやすくなっていますので是非活用して頂けたらと思います。
大まかな学習の流れ
コンテナ環境について調査して理解を深める
そもそも コンテナ とは何だろうという基本的なところですね。
検索すると多種多様なブログサイトがみつかりますので詳細は割愛します。
大雑把にまとめますとコンテナは・・・
土台イメージのコピーと追加アプリで構成されたイメージを展開・実行しているインスタンス
という解釈に至りました。
そのため、構築方法によっては意図せず多くのＣＰＵ・メモリを消費する構成も作れてしまうということがわかりました。
OSイメージが必要らしい
私の場合は本番環境がAWSのクラウドを利用することが前提です。
そのため、AWSのEC2を立ち上げるときに見かける Amazon Linux2 に近いOSイメージ（コンテナの土台イメージ）が欲しいので調べました。
オフィシャルでコンテナイメージが配布されていたのでこちらを採用することにしました。
DockerFileを書いてみよう
AWSオフィシャルのサイトからDockerFileの基本が得られますのでこちらをベースに構築しました。
以下の画像はRedisの単体実行環境を構築した際のものです。
基本中の基本のLinuxコマンドばかりです。
概ね以下のようなことを行っています。
- OSイメージの展開
- アプリのインストール
- フォルダの作成・権限設定
- AWS EC2を意識したアカウント作成
- 起動時自動実行シェルスクリプトのコピー
- 起動設定
※ちゃんと理解して欲しい＋無料ナレッジですので画像にしました。
DockerFileで出来ること
- コンテナイメージへの圧縮ファイルの展開
- ファイルのコピー・フォルダ作成・アクセス権設定
- アプリの自動起動設定
DockerFileで出来ないこと
- アプリの実行・起動
- 実行アプリへのアクセス（mysql -u root などでのサーバーアプリへ接続)
コンテナの仕様定義はどうするのか？
DockerFileが一つだけはウェブサーバーとキャッシュサーバーとＤＢサーバーが分けられないです。
AWSのクラウドサービスを利用する際は EC2・Elasticache(redis)・RDS の構成で考えています。
そのため３つに分割して構成を作る方法を調べました。
その他、以下の事項もどのようにどこで設定するのかを調べました。
- CPUやメモリの制限
- 外部からの接続ポート設定
- PC名
- Windowsフォルダの共有（Linuxからアクセス・いわゆるボリュームマウント）
- 内部・外部ネットワークの定義
上記の行いたいことについてはdocker-compose.ymlというファイルを使用することで実現できることがわかりました。
以下はRedis専用コンテナの大まかな設定です。
使い慣れた環境を構築する
NGINX+PHP-FPM＆REDIS＆MARIADB が私の基本環境です。
フレームワーク等は後から欲しいものを入れればよいのでまずはサーバーとして起動して、接続できるところまで進めました。
細かい環境構築の方法については割愛します。
私のPCは Windows 11 Pro です。
大まかに以下のことをしました。
- 「Windowsの機能の有効化または無効化」を使用して仮想環境を操作できるようにしました。
- Docker Desktopのインストール
- 各種コマンドを実行するバッチの作成
主要コマンド：docker-compose up -d --build - Docker環境完全初期化バッチの作成
Docker Desktopを利用した環境構築のフォルダ構成は以下のようになりました。
Docker環境の動作テスト
Docker Desktopのコンテナ一覧にて３つのコンテナが起動できていることが確認できます。
画像上部のコマンドプロンプトは３つのコンテナのそれぞれのCPU/メモリ使用率です。
ウェブサーバーはAmazon2として起動
/sbin/init を使用して起動しているので本来のコンテナではなく普通のLinuxサーバーとして動かしています。
この方法にしているのはまだすべての機能のテストが終わっていないからです。
DockerFileにてopenssh-serverをインストールしているので他のコンテナのredisやmariadbへの接続などもWindows上からSSH経由で操作できます。
DockerFile作成、起動シェルスクリプト作成やphp xdebug3のlinux対応などが終わったら最小アプリのみの起動に切り替える予定です。
Redis/MariaDBサーバーは最小構成で起動
Redisサーバーのtopによる起動アプリ一覧表示
ウェブサーバーの"top"コマンドによる情報と比べると、起動アプリ数やメモリ使用量がとても小さくシンプルになっています。
MariaDB サーバーのtopによる起動アプリ一覧表示
MariaDBはSQLサーバーのため、初期確保メモリがやや大きめではありますがほぼ最小限のメモリ使用量で起動しています。
Windowsからの接続テスト
Dockerとして起動していも外部からアクセスできなければ開発が円滑には進められません。
Windows PCでDockerを実行していますのでWindowsからちゃんとアクセスできるところまで確認しました。
Google Chromeにてnginx+php-fpmのウェブサーバー確認
Another Redis Desktop ManagerにてRedisサーバー確認
HeidiSQLにてDBサーバー確認
あとがき
今回のDocker学習・検証にてコンテナの仕組みが理解できました。
後はコンテナイメージをAWSのECRに登録をおこなえばAWSクラウドで利用できます。
環境が変わっても動作するのがコンテナの仕組みの利点ですので、サーバーへの反映については気軽になったと思います。
それにコンテナのベースイメージOSがAmazon2なのでこの点もAWSクラウド対応としてはかなりの強みです。
Windows上でじっくりと開発している間は完全にクラウドインスタンスは止めておいて、本番環境テストの時だけインスタンスを利用すれば費用削減にもつながります。
そういった使い方がしやすいという点でもコンテナ環境は便利だなと感じました。
コンテナ環境で不便に感じたこと
良いことを色々とまとめましたので最後にデメリットを記載します。
-
Dockerの仕組みの学習に時間が掛かる
Amazon Linux 2を使い慣れていた私が２０時間～３０時間くらいです。
Linuxが初めての方はDockerから始めるのはかなり難しいと言えます。 -
Docker Desktopでの開発効率が悪い：レイテンシ・転送速度に難がある
AWS EC2(t3.micro)のクラウドの方が体感５～１０倍以上速い。（東京リージョン）
ローカルPC上なのにファイルのダウンロード開始までに１０秒くらい掛かる。
ウェブページの表示も遅いのでトライ＆エラー時の効率がかなり悪い
2022/11/27：DNSリゾルバの設定を変更することで解決 -
メリットが魅力的なメリットに感じない（大規模プロジェクト向けの印象）
アプリバージョン切替がしやすい⇒新機能検証には便利だがテストは本番環境ですべき
ハードウェアリソースを使い切りやすい⇒ポートが葛根しそう、リソース取り合い調査が大変そう
以上になります。
ここまで読んでくれた皆様ありがとうございました。
