【イベントレポート】JAWS-UG meets Windows 〜 Windows開発者及びインフラエンジニアのためのDev&Ops On AWS 〜 #jawsug #jawsdays
はじめに
3/11(土)にTOC五反田にて行われたJAWS-DAYSに参加してきました。
今回はWindowsに焦点を当てたDev&Opsとしてセッションを受講しました。
セッション概要
[DeepDive] JAWS-UG meets Windows ～Windows開発者およびインフラエンジニアのためのDev&Ops on AWS～
SlideShare
JAWS-UG Meets Windows (JAWS Days 2017)
登壇者
アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト 渡邉源太様
アマゾンウェブサービスジャパン株式会社 ソリューションアーキテクト 福井厚様
セッションの概要について
Dev&Opsを主点として開発者、インフラ管理者視点の話をする
DevOpsとは？
ソフトウェア開発のライフサイクルは2つある。 - デリバリーパイプライン - フィードバックループ
これらのライフサイクルを高速に走らせることで「顧客の満足度」、「顧客のフィードバックをすぐに反映させる」ことを目的とする
AWSでは、DevOpsに取り組むにあたって様々なAWSプロダクトを提供している
DevOpsの話をすることの前提として「Infrastructure as code」という言葉がある
これは、「インフラを全てソフトウェア = インフラをソフトウェアにように扱う」
⇛これはオンプレではできなかったことがクラウドによって出来るようになったためより浸透していく
Infrastructure as Codeのメリット
- サーバー台数が増えても構築に時間がかからない
- コード=手順書になるのでコードを常にメンテナンスしておけば良い
- 手順を抜かしたり手順を間違う心配がない
- 同じコードを動かせば同じサーバーが出来上がる
- コードの再利用が出来、拡張もしやすくなる
-
AWSでのInfrastructure as codeを実現するべく、多くのプログラミング言語にてSDKを多く提供している
- このプログラミング言語の中で.NET coreも対応しているのでマルチプラットフォームで対応可能
Infrastructure as Code
Infrastructure as Codeを実現するにあたり、AWSの代表的なものとしてCloudFormationが挙げられる - JSON,YAMLに対応 - ドキュメントとして定義したものをデプロイ出来る
自動化のために使えるコマンドラインツールも多い。 - AWS CLI - AWS Tools for Windows Powershell
- Windowsでは、OSより上位のレイヤーの作業をPowershellを使って実行を行うことが多いことからPowershellのコマンドレットを使用できる点でもオススメしている
Automation
AWSでも既存の運用を続けることが出来る
オンプレにあるシステムをAWSに移行
↓
オンプレでやってる運用をAWSで使える(エクセル台帳を使って、管理を行う)
↓
これでは運用コストは減らない(サーバー台数が増えると管理面で大変になる)
この問題に対して、AWSではツールを代替することで運用コスト削減が可能になる - CloudWatchによるモニタリング - AWS Configによる変更管理
EC2 Systems Manager
EC2 Systems Managerを使うことで以下の恩恵を受けることが出来る - サーバーの運用コストを減らしてビジネス注力 - 品質安定 - オンプレミス、クラウド管理一元化 - セキュアなオペレーションを実現
- EC2 Systems Managerではオンプレミス環境、EC2インスタンスで動作しているWindows,Linuxに対してシステム自動構成と継続的な管理出来る
- EC2 Systems Managerを使用するにあたって、管理サーバーを立てる必要がない
Run Command
- 好きなコマンドをリモートで実行することが出来る
- JSONベースのドキュメントでコマンド・タスクを定義して管理ができる
- ポートも開ける必要がなく、セキュア運用が可能になる(パスワードを知らなくてもいい！)
「指定したインスタンスをドメインに参加させたい」を例とすると - 昔はRDPで入ってドメインに参加だった - AWSではドメイン参加用のコマンドを発行することでドメイン参加、コマンド実行等が可能になる
「Windows Nano ServerでIISのインストールしたい」を例とすると - Powershellのコマンドレットを入れることでインストールすることが出来る！
PatchManager
- ベースラインを定義してWindowsパッチを定義できる
- Patch Baselineを使ってカスタムパッチポリシーを定義
- Maintenance Window内で実施できる
- 実施されたパッチングの結果はレポートされる
パッチ提供からどれぐらい待つ必要があるのかなどを指定できる
Container
Windowsはこれからだが、ユーザーは増えると予想している
そもそもコンテナとは何か
- OS仮想化
- プロセス隔離
- イメージ
- 自動化
仮想マシンをプロセス単位でOSを使用する
- コンテナを使用したDevOpsの観点で使われている
- コンテナの中にあぷり、ミドルを含めることが出来る
- Opsはコンテナ稼働環境のみ管理する
Windowsコンテナ
WindowsServer2016からコンテナが使えるようになる
このコンテナは大きく2つ種類がある。
- WindowsServerコンテナ
- WindowsServerOS上で使える
- Dockerをインストール
- コンテナ実行
- Hyper-Vコンテナ
- OS上でHyper-Vのハイパーバイザーを動作して、その上でコンテナプロセスを起動する
- EC2上では実行することが出来ない
WindowsServer2016でコンテナを使う時の注意
通常のEC2で起動するWindowsServerAMIでは、EC2インスタンスとDockerプロセスでNWの競合が発生する。 DockerのExternalCIDRとWindowsServerのInternalCIDRがコンフリクトしてしまう そのため、Windowsコンテナを使用する時のホストに使用するAMIはMicrosoft Windows Server 2016 Base With ContainerのAMIを使いましょう！
コンテナを使う時にぶつかる壁
- 1台のサーバー上でDockerを扱うのは難しくない
- 複数台のクラスタ上でコンテナを管理するのは難しく、管理者の皆が頭に悩ませるところ
-
AWSユーザーへコンテナを使用する際の選択肢としては、ECSを使うとコンテナ管理がしやすくなる。
- AWS基盤との統合も可能になる。
-
ダイナミックポートをマッピングしたりと柔軟にコンテナを配置してくれる
-
WindowsServerコンテナはBetaであるが、サポートしており、近々GAの予定
- CloudFormation提供、ECSなどを提供する予定
注意点
- LinuxとWindowsコンテナクラスタは混在できない
- タスクのためにIAMロール追加が必要
- WindowsServerはサイズが大きいので、DLでは時間がかかるのとストレージ容量が必要
開発者よりのDevOps
継続的デリバリと継続的デプロイメントの違いは？
-
継続的デリバリ
- テスト環境まででもいいからデプロイする
- 継続的デプロイメント
- 本番環境まででもいいからデプロイする
ソフトウェアのプロセスを自動化、バグの検出、アップデート配信これが実現出来るようになる = 開発者がより幸せになる
AWS Codeシリーズ
AWSのCodeシリーズによって、Testを除く各ソフトウェアリリースフェーズに対応することが出来る
Source
AWS CodeCommitによって、gitの機能を提供
Build
AWS CodeBuildによって、ビルドを提供
Test
Testは残念ながら存在していないたので、Third Partyにて対応
Production(Deploy)
AWS CodeDeployによって、各環境へのデプロイを提供
一連のソフトウェアリリースフェーズ全体をAWS Code Pipelineで自動管理することが出来、
Codeシリーズはwindowsでも使える！
AWS CodeCommitとは
- セキュア、スケーラブルのマネージドgitソース管理
- リポジトリとしてS3を使っている
- 耐久性が優れている
- VisualStudioやEclipseからCodeCommitに繋げられるようになった
AWS CodeBuild
- ビルド
- 一時的なコンテナを作ってユニットテスト等が出来る
CodeDeploy
- あらゆるインスタンスへのデプロイを自動化に出来る
- Blue/Greenデプロイメントも出来る
- LifeCycle Hooksが使用できる
- デプロイメントの方法も選択出来る
- デプロイ作業量の調整が可能で「1つずつ」、「半分ずつ」、「全て一括」とデプロイ範囲を指定
- デプロイ先のグループを指定することが可能
Codepipeline
- 各Code系を包括して扱える
- ソフトウェアのプロセスをモデル化(見える化)が出来る様になる
- Githubにpushしたタイミングでそれを検知してデプロイすることも出来る様になる
C# Lambda
これまではnode.jsなどが使用できていたが、C#がLambdaで使えるようになった - NET Coreベースで動作 - WIn32apiやCOMコンポーネントは呼べない - EC2で動いていることで呼び出せない - VisualStudioで統合された環境を利用できる - dotnet CLIベースの開発も可能になる
Lambda関数としてハンドラの名前は自由に指定することが出来る
Lambdaで使っている言語は何を基準にすれば良い？
- 企業・組織で既に保有しているソースに言語を合わせるのも一つの手と思われる
- Lambdaはイベントに対して処理を実行するので、動作が早いものを入れておくといい
- スクリプト系の方が有利な気がしている
- Javaのクラスのローディングやセットアップに時間がかかる
- インタプリタ系の方が良いかもしれない
最後に
渡邉様、福井様には各担当者視点でお話をして頂いたことでそれぞの立ち位置でどのようなAWSサービスを使うということが改めて整理できました。
オペレーションチームとして「EC2 Systems Manager」の登場は衝撃でしたのでこれからも注目したいサービスと考えております。
弊社記事
今回お話を頂きましたAWSサービスは弊社ブログにて記事が御座います。 あわせてご覧頂ければと思います。
