JAWS-UG Meets Windows (JAWS Days 2017)
2 likes3,837 views
2017年3月11日 JAWS Days 2017「JAWS-UG Meets Windows」の講演資料です
JAWS-UG Meets Windows (JAWS Days 2017)
- 1. JAWS-UG Meets Windows ～Windows開発者およびインフラエンジニアのための Dev&Ops on AWS～ 2017年3月11日 アマゾン ウェブ サービス ジャパン株式会社 ソリューションアーキテクト 渡邉源太/福井厚
- 2. 自己紹介 • 名前 - 渡邉源太 • 所属 - アマゾンウェブサービスジャパン株式会社 • 技術本部レディネスソリューション部 • ソリューションアーキテクト • エンタープライズのお客様支援を経て、現在はAWSのエン タープライズアプリケーションを担当
- 3. 自己紹介 名前 福井 厚（ふくい あつし）fatsushi@ 所属 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部エンタープライズ ソリューション部 ソリューション アーキテクト 前職 エンタープライズ アプリケーション開発コンサルタント 好きなAWSサービス AWS Code シリーズ、AWS IoT、Lambda（C#）
- 4. Dev & Ops
- 5. DevOpsとは? DevOps = このライフサイクル高速化の効率 開発者 顧客 releasetestbuild plan monitor デリバリーパイプライン フィードバックループ ソフトウェア開発のライフサイクル
- 6. DevOpsタスクとAWSサービスの位置付け MonitorProvisionDeployTestBuildCode Elastic Beanstalk OpsWorks for Chef Automate OpsWorks Stacks Cloud Watch Cloud Formation Code Deploy Code Commit Code Pipeline Code Build
- 8. Infrastructure as Codeのメリット • サーバーの台数が増えても構築に時間がかからない • コード＝手順書となるのでコードを常にメンテナンスし ておけば良い • 手順を抜かしたり手順を間違う心配がない • 同じコードを動かせば同じサーバーが出来上がる • コードで記述されているので再利用が容易である • 他のプロジェクトでコードを使いまわすことで無駄を省 ける
- 9. AWSでのInfrastructure as Code Java Python (boto) PHP .NET Ruby Node.js AWS Tools for Windows PowerShell AWS CLI JavaScript CloudFormation OpsWorks Elastic Beanstalk
- 10. CloudFormation • AWS環境の Infrastructure as Code を実現 • What’s New: YAML対応 / ChangeSet 10 MonitorProvisionDeployTestBuildCode 作成 / 削除 AWS CloudFormation AWS リソースの 作成 / 削除 テンプレート スタック - 作成するリソースの 基本的な定義 - JSON テキストファイル - AWS リソースの集合 AWS環境の設定管理&オーケストレーションサービス
- 11. 自動化のためのコマンドラインツール AWS Command Line Interface (CLI) • “aws”という名前の単一コマンドでAWSサービスを操作可能 • プラットフォームや開発言語などが限定されない Windows, Linux, Mac, Unixなど • S3用にはsyncなどの便利な機能あり AWS Tools for Windows PowerShell • “AWSPowerShell”モジュール内のコマンドレットから、ほとん どのAWSサービスを操作可能 • PowerShellの強力なシェル機能が利用できる
- 12. （参考）Pro PowerShell for Amazon Web Services: DevOps for the AWS Cloud • Create, manage, and terminate Windows servers in the cloud • Manage storage options including backup and recovery • Configure a virtual network including subnets and route tables • Secure your servers using security groups and access control lists • Use Auto Scaling to respond to changing conditions • Deploy SQL Server using Relational Database Service • Use Simple Storage Service (S3) to reliably store and archive data • Control access to resources using Identity and Access Management (IAM) https://www.amazon.co.jp/Pro-PowerShell-Amazon-Web-Services-ebook/dp/B00HG2CQ3O/
- 13. Automation
- 14. AWSでも既存の運用が可能 • 既存の運用ルールをAWSに適用する事は可能 - WikiやExcelが悪という訳ではない - ドキュメントへの情報記録、管理は必要になる - 運用コストはあまり減らない • 一部のツールは代替も可能 - CloudWatchでの監視、AWS Configでの変更管理、 etc…
- 15. Amazon EC2 Systems Managerを使うことで • 運用コストを減らしてビジネスに注力 • 運用の品質安定、標準化が可能 • オンプレミス、クラウドの管理を一元化 • セキュアなオペレーションを実現
- 16. Amazon EC2 Systems Manager Amazon EC2、またはオンプレミスで実行されるWindows、 Linuxに対してシステムの自動構成と継続的な管理を可能に する一連の機能 Amazon EC2 Amazon EC2 Systems Manager
- 17. Run Command リモートから任意のコマンド実行が可能 ソフトウェアのインストール、パッチング、アップデート ユーザーの追加・削除、サービスの起動・停止、状態取得 JSONベースのドキュメントでコマンド、タスクを定義 定義済みのドキュメントも提供、コミュニティ版もあり 実行結果はS3に保存可能、実行状態に合わせてSNSを使って通知 SSH、RDPの接続ポートを閉じる事でセキュアに運用 管理作業をリモートから実行 17
- 18. Run Commandによるドメイン参加 • 指定したインスタンスのドメインへの参加 • コマンド実行のステータス確認 $domainJoinCommand=Send-SSMCommand -InstanceId i-xxxxxxxx - DocumentName AWS-JoinDirectoryServiceDomain -Parameter @{directoryId = 'd-xxxxxxxxx'; directoryName = 'corp.example.com'} Get-SSMCommand -CommandId $domainJoinCommand.CommandId -Details $true
- 19. Nano ServerへのIISのインストール • パラメータの指定とコマンドの実行 • コマンド実行のステータス確認 $commands = @(‘ Install-PackageProvider –Name NuGet –Force Save-Module –Path “$env:ProgramFiles¥WindowsPowerShell¥Modules” – Name NanoServerPackage –MinimumVersion 1.0.0.0 Import-PackageProvider NanoServerPackage Install-NanoServerPackage –Name Microsoft-NanoServer-IIS-Package Start-Service W3SVC ‘) $runPSCommand=Send-SSMCommand -InstanceId i-xxxxxxxx -DocumentName AWS-RunPowerShellScript -Parameter @{‘commands’ = $commands} Get-SSMCommand -CommandId $runPSCommand.CommandId
- 20. Patch Manager Patch Baselineを使ってカスタムパッチポリシーを定義 例：クリティカルなパッチが提供された場合には1日後に適用 パッチ適用は指定したMaintenance Window内で実施 実施されたパッチングの結果はレポートされる インストールされたパッチ、スキップ、失敗したパッチ等 重要なアップデートやゼロデイ脆弱性への対応を自動化、時間を短縮 ベースラインを定義してWindowsのパッチを適用 20
- 21. Patch Manager • Patch Baselineで適用す る(しない)ルールを定義 • パッチが提供されてから 待たせる日時を指定 • 対象OSバージョンを指定 21
- 22. Patch Manager • 作成したBaselineをMaintenance Windowsで指定 - Targets → Register new targetsから設定 - インスタンス個別、タグ指定、Patch Groupで指定
- 23. Container
- 24. コンテナとは何か？ • OS仮想化 • プロセス隔離 • イメージ • 自動化Server Guest OS Bins/Libs Bins/Libs App2App1
- 25. コンテナを使用したDevOps • コンテナにアプリ・ミドルウェア・設定が含まれる • DevとOpsにおける環境の整合が不要 • 本番と同じ構成で開発およびテストが可能 • Opsはコンテナ稼働環境のみ管理すればよい Build Test Productio n Source Application Image Provision Config
- 26. Windowsコンテナ • Windows Serverコンテナ - プロセスと名前空間の分離テクノロジを使用してア プリケーションを分離 - Windows Server 2016 Base with Containers AMI を用意 • Hyper-Vコンテナ - 高度に最適化された仮想マシンで各コンテナを実行 - EC2上では実行できない
- 27. Windows Serverコンテナの実行 • Dockerのインストール • Dockerコンテナの実行 Install-Module -Name DockerMsftProvider -Repository PSGallery -Force Install-Package -Name docker -ProviderName DockerMsftProvider Restart-Computer -Force docker run microsoft/iis
- 28. Windows Server 2016 インスタンスでの Docker コ ンテナの競合 • Windows Server 2016インスタンスでDockerを実行す るためには、”Microsoft Windows Server 2016 Base with Container” AMIを使用する必要がある • EC2のインターナルCIDR（172.31.0.0/16）とDocker 用のCIDR（172.16.0.0/12）がコンフリクトするのを ふせぐためdaemon.jsonで172.17.0.0/16を指定してい る
- 30. しかし、複数台のクラスタ上で管理するのは困難 Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS Server Guest OS AZ 1 AZ 2 AZ 3
- 31. Amazon EC2 Container Service コンテナ管理を あらゆるスケールで 柔軟なコンテナの配置 AWSの基盤との連携
- 32. Docker Task Container Instance Amazon ECS Container ECS Agent ELB Internet ELB User / Scheduler API Cluster Management Engine Task Container Docker Task Container Instance Container ECS Agent Task Container Docker Task Container Instance Container ECS Agent Task Container AZ 1 AZ 2 Key/Value Store Agent Communication Service
- 33. Amazon ECS – Windowsコンテナ（Beta） • Amazon EC2 Container Service (ECS)でWindowsコンテナをパ ブリックベータとしてサポート - Amazon ECS Container AgentをGitHub上に公開 （ https://github.com/aws/amazon-ecs-agent ） - Windowsコンテナを実行するためのCloudFormationテンプ レートも提供 • 注意点 - Linuxコンテナクラスタとの混在はできない - タスクのためのIAMロールに追加の設定が必要 - Windows ServerのDockerイメージは比較的大きいためダウン ロードにはより多くの時間とストレージ容量が必要
- 34. for Developer
- 35. • 他のシステムと の統合テスト • ロードテスト • UIテスト • 侵入テスト リリースプロセスの4つの主なフェーズ ソース ビルド テスト 運用 • .javaファイル などのソース コードをチェッ クイン • 新しいコードの ピアレビュー • コードの コンパイル • ユニットテスト • スタイルチェッ カー • コードメトリック • コンテナイメージ の作成 • 本番環境にデプロイ
- 36. リリースプロセスのレベル ソース ビルド テスト 運用 継続的インテグレーション 継続的デリバリ 継続的デプロイメント
- 39. AWS Code シリーズ Source Build Test Production ソフトウェア リリース フェーズ
- 40. Source Build Test Production AWS CodeCommit ソフトウェア リリース フェーズ AWS Code シリーズ
- 41. Source Build Test Production AWS CodeBuild ソフトウェア リリース フェーズ AWS Code シリーズ
- 42. Source Build Test Production Third Party Tooling ソフトウェア リリース フェーズ AWS Code シリーズ
- 43. Source Build Test Production AWS CodeDeploy ソフトウェア リリース フェーズ AWS Code シリーズ
- 44. Source Build Test Production EC2 On-Prem AWS CodeDeploy ソフトウェア リリース フェーズ AWS Code シリーズ
- 45. Source Build Test Production Third Party Tooling AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS CodePipeline ソフトウェア リリース フェーズ AWS Code シリーズ
- 47. セキュア、スケーラブル、マネージドなGitソース管理 スターンダードなGit ツールが利用可能 Amazon S3のスケーラビリティ, 可用性, 堅牢なスト レージを利用 顧客独自のキーによる保存暗号化 レポジトリサイズの上限なし Post commit hooks で SNS/Lambdaを呼び出せる AWS CodeCommit
- 49. AWS CodeCommit git pull/push CodeCommit Git オブジェクトは Amazon S3で管理 Git インデックスは Amazon DynamoDBで管理 暗号化キーは AWS KMSで管理 SSH or HTTPS
- 50. Build & test your application https://secure.flickr.com/photos/spenceyc/7481166880
- 52. どのように動作するのか? 1. ソースコードのダウンロード 2. 一時的なコンテナ内でbuildspecで構成されたコマンド を実行（ビルドごとに新規に作成される） 3. マネジメント コンソールとCloudWatch Logs にビルド の出力結果が送信される 4. 生成されたアーティファクトをS3バケットにアップ ロード
- 53. Deploying your applications https://secure.flickr.com/photos/simononly/15386966677
- 55. *Gray events are non-scriptable Lifecycle Hooks
- 56. version: 0.0 os: linux files: - source: / destination: /var/www/html permissions: - object: /var/www/html pattern: “*.html” owner: root group: root mode: 755 hooks: ApplicationStop: - location: scripts/deregister_from_elb.sh BeforeInstall: - location: scripts/install_dependencies.sh ApplicationStart: - location: scripts/start_httpd.sh ValidateService: - location: scripts/test_site.sh - location: scripts/register_with_elb.sh • ELBへのインスタンスの追加と 削除 • 依存パッケージのインストール • Apacheの起動 • デプロイの成功を確認 • 他にも！ • アプリケーションファイルと 設定ファイルをそれぞれの ディレクトリに送信 • 特定のディレクトリとファイル のアクセス許可を設定 appspec.ymlの例
- 57. v2 v2 v2 v2 v2 v2 1つずつ 半分ずつ すべて一度に v2 v2 v2 v1 v1 v1 v2 v1 v1 v1 v1 v1 エージェント 開発デプロイグループ または 本番デプロイグループ デプロイの作業量とグループの選択 エージェント エージェント エージェント エージェント エージェント エージェント エージェント
- 58. Orchestrating build and deploy with a pipeline https://www.flickr.com/photos/seattlemunicipalarchives/12504672623/
- 61. 8. ビルドアーティファク トを取得 EC2インスタンス CodePipeline Source Source GitHub Build JenkinsOnEC2 Jenkins Deploy JavaApp Elastic Beanstalk ソースアーティファクト S3 ビルドアーティファクト S3 5. ソースアーティファクト を取得 1. 変更を取得 6. ビルドアーティファクト を格納 3. ジョブをポーリング 4. ジョブを承認 7. 成功を通知 9. ビルドアーティファクト をデプロイ Elastic Beanstalk Webコンテナ Javaアプ リ MyApplication
- 62. AWS サービス統合 Source Invoke Logic Deploy AWS Elastic Beanstalk Amazon S3 AWS CodeDeployAWS Lambda AWS CodeBuild AWS CodeCommit AWS OpsWorks AWS CloudFormation
- 64. AWS Lambda for C#とは • .NET Core で動作 - Win32 API や COMコンポーネントは呼べません • Visual Studio に統合された環境を利用できます - AWS Tools for Visual Studio 最新版をインストー ルしてください • dotnet CLIベースの開発も可能です - Mac や Linux 上で開発できます 64
- 65. Lambda関数ハンドラ（C#） • クラスの静的またはインスタンス メソッドとして定義可 能 • Contextオブジェクトを利用する場合は、メソッド パラ メータとしてILambdaContext型を指定 65 returnType handler-name(inputType input, ILambdaContext context) { ... }
- 66. C# Lambdaの作成 • C#のメソッドをLambda関数として実行するためには、 AWS Lambdaに対してハンドラ文字列を渡す必要があ る - ”アセンブリ::タイプ::メソッド” 66
- 67. AWS Lambda C# Project Template 67
- 68. AWS Labmda C# Blue Print 68
- 69. Publish to AWS Lambda 69
- 70. Publish to AWS Lambda 70
- 72. Demo 72
- 73. Let‘s develop Serverless Application!! 73
- 74. AWS CodePipeline, AWS CodeBuild, Amazon ECR, AWS CloudFormationを利用したAmazon ECSへの継続的デプロイメント http://amzn.to/2l1PMyh
- 75. Dev ♥ Ops
- 76. AWS – Windows Users Meetup https://awswinuser.connpass.com/
- 77. 77