クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
•
15 likes•2,940 views
ネットワークプログラマビリティ勉強会＃５で発表した資料です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
Similar to クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code (20)
More from skipping classes
Recently uploaded
Recently uploaded (8)
クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code
- 2. 今日の話 ▷ ２０〜２５分 IaaSやクラウド基盤を使ったシステム構築が一般的になった中、 その上で構築されるシステムの､とりわけネットワークの Infrastructure as Codeはどういった形で実現されているのか ▷ ５〜１０分 ネットワークの要素とコード化
- 3. 今日の話 出現する要素 ▷ SDN(一部｡仮想寄り＆サーバ寄り) ▷ オーケストレーション､自動化 ▷ その他(コード) ネットワークの､というタイトルですが、 それ以外の要素が沢山でてきます。
- 7. 宣言型のプロビジョニングツールがたくさん登場しました。 各々のリソース記述は何度やっても同じになる事(冪等性)が 特徴として挙げられます｡ (Chef､Puppet､Ansibleなど) Infrastructure as Codeのおさらい 参考：ネットワークプログラマビリティ勉強会＃１
- 8. Chefで書いた場合の例 Infrastructure as Codeのおさらい package ['httpd’] do action :install End service "httpd" do action [ :enable, :start ] end template '/etc/httpd/conf/httpd.conf' do owner 'root' group 'root' mode 0644 source 'httpd.conf.erb' notifies :reload, 'service[httpd]', :delayed variables( document_root: ***, log_level: *** ) end apacheの インストール 何度流しても 同じ状態になる 値を埋めた設定ファイルを 配置して、設定をリロード サービスを起動して 有効にする パッケージを インストール
- 11. IaaSやクラウド基盤では､API操作によって サーバ自体や､サーバ以外のインフラリソースのコントロール をユーザがプログラミングできるのが一般的になりました｡ ネットワークやストレージもここに含まれています｡ (Software Defined Infrastructureが示す自動化部分の一部) もっと幅広く応用が効くように Elastic IP Amazon Route 53 Amazon VPC route table router Internet gateway Elastic Load Balancing
- 12. APIが備わっていることによって､ 1. ネットワークを構築してから 2. サーバを起動して 3. Chefなどを実行してサーバの中を整備して 4. そのままクラスタリングして監視を入れて 5. DNSを設定して といったことが､コードで大体､環境によっては全て記述できる ようになっています｡これによって､サーバの中身だけではなく ネットワークなども含んだシステム全体の構成自体をコードで 版管理できるようになります。 もっと幅広く応用が効くように
- 17. この場合ネットワークのコード化は？ OpenStack(Neutron)を例にとったコード(python)の例 #!/usr/bin/env python from neutronclient.v2_0 import client from credentials import get_credentials network_name = 'sample_network' credentials = get_credentials() neutron = client.Client(**credentials) try: body_sample = {'network': {'name': network_name, 'admin_state_up': True}} netw = neutron.create_network(body=body_sample) net_dict = netw['network'] network_id = net_dict['id'] print('Network %s created' % network_id) body_create_subnet = {'subnets': [{'cidr': '192.168.199.0/24', 'ip_version': 4, 'network_id': network_id}]} subnet = neutron.create_subnet(body=body_create_subnet) print('Created subnet %s' % subnet) finally: print("Execution completed") 裏で「色々なもの」 に処理を丸投げする 例：midonet 仮想Bridge作成 仮想BridgeのDHCP エントリ作成 subnetの作成 networkの作成
- 19. オーケストレータ だいたいこんな感じのことがまとめて反映されます。 ▷ 記述した仮想ネットワークを構築 ▷ 記述したACLをネットワークに対して付与 ▷ 記述したインスタンスを､指定したイメージから､記述した依存順で起動 ▷ 指定したボリュームをインスタンスにアタッチする ▷ 指定した仮想ネットワークに接続されるNICをインスタンスにアタッチ し､IPアドレスを割り当てる ▷ インスタンス起動時に､記述した内容のコード(shell)を実行 ▷ ものによっては起動したインスタンス内部のセットアップ (続きとしてchefなどのプロビジョナを実行する機能) ▷ テンプレートを更新して再実行すると､その差分を反映してくれたりする (追加されたインスタンスの起動など)
- 20. テンプレートの例 (CFN) { … "Resources" : { "VPC" : { "Type" : "AWS::EC2::VPC", "Properties" : { "CidrBlock" : "10.0.0.0/16" } }, "Subnet" : { "Type" : "AWS::EC2::Subnet", "Properties" : { "CidrBlock" : "10.0.1.0/24", "VpcId" : { "Ref" : "VPC" } } }, "InternetGateway" : { "Type" : "AWS::EC2::InternetGateway" }, "VPCGatewayAttachment" : { "Type" : "AWS::EC2::VPCGatewayAttachment", "Properties" : { "InternetGatewayId" : { "Ref" : "InternetGateway" }, "VpcId" : { "Ref" : "VPC" } } }, "RouteTable" : { "Type" : "AWS::EC2::RouteTable", "Properties" : { "VpcId" : { "Ref" : "VPC" } } }, "RouteToInternetGateway" : { "Type" : "AWS::EC2::Route", "Properties" : { "DestinationCidrBlock" : "0.0.0.0/0", "GatewayId" : { "Ref" : "InternetGateway" }, "RouteTableId" : { "Ref" : "RouteTable" } } }, "SubnetRouteTableAssociation" : { "Type" : "AWS::EC2::SubnetRouteTableAssociation", "Properties" : { "SubnetId" : { "Ref" : "Subnet" }, "RouteTableId" : { "Ref" : "RouteTable" } } }, "WebServer" : { "Type" : "AWS::EC2::Instance", "Metadata" : { "Role" : "web", "Frontend" : "true" }, "Properties" : { "ImageId" : { "Ref" : "WebImageId" }, "InstanceType" : { "Ref" : "WebInstanceType" }, "KeyName" : { "Ref" : "KeyName" }, "NetworkInterfaces" : [{ "DeviceIndex" : "0", "NetworkInterfaceId" : { "Ref" : "WebNetworkInterface" } }], } }, Subnet Internet Gateway Route Table VMとNICのAttach Route TableとSubnetの 紐付け
- 23. 自動テストの例 (Serverspec) describe service('httpd') do it { should be_running } end # Cehck listen port describe port(80) do it { should be_listening.with('tcp') } end # Check connect ap servers describe 'connect ap_servers' do ap_servers = property[:servers].each_value.select do |server| server[:roles].include?('ap') end ap_servers.each do |server| describe command("hping3 -S #{server[:private_ip]} -p 8009 -c 5") do its(:stdout) { should match(/sport=8009 flags=SA/) } end end end このサーバから別サーバの8009/tcpに接続できるか Listenしているか サービスが稼働しているか
- 26. Terraform SDNについて、コントロール層で設定をコード化できることが書かれています。 Software Defined Networking Software Defined Networking (SDN) is becoming increasingly prevalent in the datacenter, as it provides more control to operators and developers and allows the network to better support the applications running on top. Most SDN implementations have a control layer and infrastructure layer. Terraform can be used to codify the configuration for software defined networks. This configuration can then be used by Terraform to automatically setup and modify settings by interfacing with the control layer. This allows configuration to be versioned and changes to be automated. As an example, AWS VPC is one of the most commonly used SDN implementations, and can be configured by Terraform. https://www.terraform.io/intro/use-cases.html
- 28. テンプレートの例 (Terraform) provider "aws" { access_key = "*****" secret_key = "*****" region = "ap-northeast-1" } resource "aws_vpc" "vpc1" { cidr_block = "10.0.0.0/16" tags { Name = "vpc1" } } resource "aws_subnet" "vpc1-subnet1" { vpc_id = "${aws_vpc.vpc1.id}" cidr_block = "10.0.1.0/24" availability_zone = "ap-northeast-1a" tags { Name = "vpc1-subnet1" } } resource "aws_internet_gateway" "vpc1-igw" { vpc_id = "${aws_vpc.vpc1.id}" tags { Name = "vpc1-igw" } } resource "aws_route_table" "public" { vpc_id = "${aws_vpc.vpc1.id}" route { cidr_block = "0.0.0.0/0" … awsを利用 Subnet作成 Internet Gateway作成 providerによって､使えるresourceと パラメータが違いますが､記法自体は同じです ※providerはpluginで追加可能 VPCの作成 Route Table作成
- 29. ここまでのまとめ ▷ サーバだけでなく､APIを利用してネットワークなども プログラムから自動構成できるのが当たり前になった ▷ オーケストレーションで､宣言的に書いたいろいろな リソースの組み合わせをIaaSやクラウド基盤に反映できる ようになった ▷ いろいろなアプローチがあるものの､コードで複数環境の リソースを組み合わせることもできるようになってきた
- 35. おわりに 例えばノードの設定は手続きが現実的な状態だと思いますが､ 基本的に手続き的な手法とノード設定は相性が悪いので､ (同じコマンドを2度流す､あるいは順序が違うとエラーとか) ▷ OpenDaylight(MD-SAL)か何かが広がり ▷ YangModelなどが出揃って ▷ RESTCONF(NETCONF)などでNBとSBが整備されて ▷ そこに宣言的なネットワークコードを当て､機器群に反映 できる ようになったら自動化が捗るかも､とか思います｡ (装置利用者は昔から皆思ってそうですが…)
- 37. Thank you.