狠狠撸

狠狠撸Share a Scribd company logo
@ネットワークプログラマビリティ勉強会 #5
クラウドを活用したシステム構築における
ネットワークのInfrastructure as Code
今日の話
? 20?25分
IaaSやクラウド基盤を使ったシステム構築が一般的になった中、
その上で構築されるシステムの?とりわけネットワークの
Infrastructure as Codeはどういった形で実現されているのか
? 5?10分
ネットワークの要素とコード化
今日の話
出現する要素
? SDN(一部?仮想寄り&サーバ寄り)
? オーケストレーション?自動化
? その他(コード)
ネットワークの?というタイトルですが、
それ以外の要素が沢山でてきます。
20?25分
IaaSやクラ(中略)ットワークのInfrastructure as Code
元々はサーバのミドルウェア、場合によっては
アプリケーションも含む構成管理の話でした。
外部DSLや内部DSL?あるいはプログラミング言語そのもので
記述し?実行することでインフラを構築できる?
という考え方です。
Infrastructure as Codeのおさらい
管理されたコードが正?構築されたインフラはそのコードの
実行結果を反映したものであるため?プログラム同様?
バージョン管理ができる事になります。
Infrastructure as Codeのおさらい
コードを読めば
状態がわかる
宣言型のプロビジョニングツールがたくさん登場しました。
各々のリソース記述は何度やっても同じになる事(冪等性)が
特徴として挙げられます? (Chef?Puppet?Ansibleなど)
Infrastructure as Codeのおさらい
参考:ネットワークプログラマビリティ勉強会#1
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の
インストール
何度流しても
同じ状態になる
値を埋めた設定ファイルを
配置して、設定をリロード
サービスを起動して
有効にする
パッケージを
インストール
簡単?迅速にリソースが確保できるのが一般的になってきた事
もあり?Immutable Infrastructureという概念がでてきました?
?変更されないインフラ?ですが?この意味するところは?
?インフラとは常にコードを変更して反映するだけ?
です?構築後には手で変更を加えないことを指します?
Immutable Infrastructure
よくセットで出る話として?バージョンアップ時は丸ごと
もう1つサーバを作り?問題がなければそのままLBやDNSで
切り替え?古いものは破棄する??Blue-Green Deployment?
と呼ばれる手法があります?(冪等性不要論がでてきたりする)
Dockerなどコンテナが流行りはじめ?より身近になってきました?
Blue-Green Deployment
参考:ネットワークプログラマビリティ勉強会#2
コードを更新して再構築
問題がなければ切替え
IaaSやクラウド基盤では?API操作によって
サーバ自体や?サーバ以外のインフラリソースのコントロール
をユーザがプログラミングできるのが一般的になりました?
ネットワークやストレージもここに含まれています?
(Software Defined Infrastructureが示す自動化部分の一部)
もっと幅広く応用が効くように
Elastic IP
Amazon
Route 53
Amazon VPC
route table
router
Internet
gateway
Elastic Load
Balancing
APIが備わっていることによって?
1. ネットワークを構築してから
2. サーバを起動して
3. Chefなどを実行してサーバの中を整備して
4. そのままクラスタリングして監視を入れて
5. DNSを設定して
といったことが?コードで大体?環境によっては全て記述できる
ようになっています?これによって?サーバの中身だけではなく
ネットワークなども含んだシステム全体の構成自体をコードで
版管理できるようになります。
もっと幅広く応用が効くように
先述のとおり?APIの実行?SDKからのプログラム実行で?簡単に
稼働するシステムに必要なネットワークを構築することができ
るようになりました。
このあたりのAPIでは?ネットワークノードのコントロールや
トポロジの構成といった部分は基本的に提供者側に隠蔽され?
サーバエンジニアが必要とする形でリソースを提供します?
つまり??ネットワークはつながるもの?という前提があります?
この場合ネットワークのコード化は?
参考:ネットワークプログラマビリティ勉強会#3
IaaSやクラウド基盤は利用者の要求に応じて物理ネットワーク
から任意のネットワークとしてリソースを払い出せる必要があ
り?クラウド基盤ではここを?色々なもの?と連携して実現してい
ます。
従って?これらの基盤から提供されるネットワークは基本的に
仮想ネットワークで?簡単に色々できる環境が手に入ります。
この場合ネットワークのコード化は?
この場合ネットワークのコード化は?
?色々なもの?の例(提供者側が基盤として利用)
http://各ベンダ様/
このレイヤで今一番よく聞くであろう例:Neutron API
この場合ネットワークのコード化は?
参考:ネットワークプログラマビリティ勉強会#2
この場合ネットワークのコード化は?
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の作成
オーケストレータ
オーケストレータは?所定のコードでシステム
の有様を宣言的ないしは一部手続的に記述
し、書いたとおりにリソースを積み上げて
(スタック)?IaaSやクラウド基盤上に実現しま
す。
更新時は?テンプレートを変更してスタックを
Updateすると差分だけを反映してくれたり
します。
https://media.amazonwebservices.com/blog/2013/cloudformation/nested/stacks/2.png
オーケストレータ
だいたいこんな感じのことがまとめて反映されます。
? 記述した仮想ネットワークを構築
? 記述したACLをネットワークに対して付与
? 記述したインスタンスを?指定したイメージから?記述した依存順で起動
? 指定したボリュームをインスタンスにアタッチする
? 指定した仮想ネットワークに接続されるNICをインスタンスにアタッチ
し?IPアドレスを割り当てる
? インスタンス起動時に?記述した内容のコード(shell)を実行
? ものによっては起動したインスタンス内部のセットアップ
(続きとしてchefなどのプロビジョナを実行する機能)
? テンプレートを更新して再実行すると?その差分を反映してくれたりする
(追加されたインスタンスの起動など)
テンプレートの例 (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の
紐付け
ツールで自動テスト?CIもできる
?ネットワークはつながる?という前提のため?
ノードの設定がどう?といった試験は行う対象がないのですが?
スタック構築後にServerspecやInfraTasterなどを実行すれば?
構築後に正しくサービスへアクセスできるACLが組まれている
か?ルーティングテーブルが正しく設定されているか?ロードバ
ランスは設定したとおりに稼働しているかといった事が試験で
きます?
自動でVPNを張るなら?そこも疎通を確認したりできます?
参考:ネットワークプログラマビリティ勉強会#1、#4
ツールで自動テスト?CIもできる
BlueGreen-Deploymentと組み合わせると?
構築して?テストした結果のインフラ(サーバだけではなく?
ネットワークごと)にバトンタッチする?といったことも可能に
なります。
自動テストの例 (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しているか
サービスが稼働しているか
複数の環境がターゲットだと?
オーケストレータは宣言的に記述できて便利ですが?IaaS?
クラウド基盤付属のもので他の基盤で使えなかったり?
フォーマットに互換性があっても機能が未対応だったり?
色々困ることがあります。
複数のクラウドをうまく利用する?という形も取りにくかったり?
オーケストレーションの発展
使いたいクラウド(IaaSだけではなく?その上のレベルの
サービスも)をうまく組み合わせてシステムを構成できる
オーケストレータがでてきました。
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
Terraform
? どの基盤(あるいはサービス)の?
provisionerで定義
? なんのリソースを?どういうパラメータで?
resourceで定義
宣言的にテンプレートを記述して?plan(実行したらどの
リソースがどうなる?という変化を事前に確認できるDry-run)?
apply(実際のインフラへの反映)などを行うことができます。
テンプレートの例 (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作成
ここまでのまとめ
? サーバだけでなく?APIを利用してネットワークなども
プログラムから自動構成できるのが当たり前になった
? オーケストレーションで?宣言的に書いたいろいろな
リソースの組み合わせをIaaSやクラウド基盤に反映できる
ようになった
? いろいろなアプローチがあるものの?コードで複数環境の
リソースを組み合わせることもできるようになってきた
5分?10分
ネットワーク要素とのコード化
ネットワークの構成要素
ここまで?特定条件下のネットワークのコードについて見まし
たが?今更ですが??ネットワーク?の構成要素ってそもそも何で
しょう?
Node?Link?Path?MAC?VLAN?Port?VLAN?IP?
Endpoint?Subnet?ACL?DHCP?DNS?LB?VPN?VIP?
NAT?FW?Router/Routing?Flow?QoS?Protocols?…
思いついたものを本当に適当に書きましたが?使う人によって
ほしい要素とか話題になる要素のレベルが全く違います。
ネットワークコードとレイヤの色々
? CloudFormationみたいなもの
外部DSLをコードとしたネットワーク記述?
?ネットワークは繋がるもの?が下地にあり?仮想ネットワーク
やサーバ以上を見る人向け?ACLなど?ある程度NFV(ネットワー
ク機能という意味での)も含んでいる。
? OdenOSなど
プログラム自体をコードとしたネットワーク記述?
(あるいはREST)
どのようにつながるか?トポロジのコントロールが主体?
複数のレイヤに跨って?これを管理することができる?
コード記述の標準フォーマット
必要があるかどうかは現時点ではわかりませんが?このへんの
有り様を一様に記述できる記法ってあるんでしょうか?
提供者側も利用者側も?大体統一的な書き方でネットワークが
定義できたら?全体管理も便利になる気がします?
Terraformのように?
「どこかに存在するリソースが?どのようになればよいか」
※リソースの種類は追加可能
を上から下まで統一的な記法で記述できれば(一部手続きとし
ても)?コントローラやツールも作りやすくなったりしないで
しょうか?
おわりに
利用者目線(多分)で話しましたが、提供者目線(多分)で便
利にならないかな、と思うこともあります。
おわりに
例えばノードの設定は手続きが現実的な状態だと思いますが?
基本的に手続き的な手法とノード設定は相性が悪いので?
(同じコマンドを2度流す?あるいは順序が違うとエラーとか)
? OpenDaylight(MD-SAL)か何かが広がり
? YangModelなどが出揃って
? RESTCONF(NETCONF)などでNBとSBが整備されて
? そこに宣言的なネットワークコードを当て?機器群に反映
できる
ようになったら自動化が捗るかも?とか思います?
(装置利用者は昔から皆思ってそうですが…)
おわりに
さいごに??物理と仮想?という話について?
そう遠くない将来?最終的に汎用サーバと仮想機能だけで
全部実現できる?完全SoftwareDefinedな世の中がくるかも
しれません?
(素人なのでよくわかりませんが?テレコムノードの仮想化と
いう単語を最近聞いた気がします)
そういうことも考えると?サーバ内でのノードの使い捨てと
いった話が現れる可能性もあり?どんなネットワーク要素も
コードで記述できるようにする考え方は?決して無駄なこと
ではなさそうです?
Thank you.

More Related Content

クラウドを活用したシステム開発における、ネットワークのInfrastructure as Code