Google Cloud Certified - Professional Cloud Architect に合格しました

gcp

cloud.google.com

シリーズIDは2000後半でした。今年頭に合格した人が1000前半だったことを考えると順調に増えていってますねー。

AWS のソリューションアーキテクトアソシエイトよりは難しかったと思います。
(プロフェッショナルはまだ受けたことないのでわからない)


ちなみに

英語版だとAssociate Cloud Engineer というのがベータで始まったので、
AWS ソリューションアーキテクトアソシエイト相当はこの資格になるのかな？

rancher v1.0 memo

rancher

version 1.0 時代のmemo 見つかったので引っ張り出してきた。
最新は1.4 なので色々変わってると思うけど。

http://rancher.com/rancher-os/

  • iso イメージからboot
  • 自動的にコンソールログイン、DHCPでIP取得
  • 作業はrancherユーザ。sudo でroot権限使う。
  • cloud-config.yaml を書いてros コマンドでinstall

- sshの公開鍵もこれに書く
- vCenterのコンソールからコピペは難しいので、作業用のためにrancherユーザにパスワード設定して、sshで入って作業するのもあり？

sudo ros install -c cloud-config.yml -d /dev/sda
sudo ros service list
sudo ros service enable open-vm-tools
sudo ros service up open-vm-tools
sudo ros service enable rancher-server
sudo ros service up rancher-server

cloud-config.yaml sample

#cloud-config
hostname: rancheros1-1
ssh_authorized_keys:
  - ssh-rsa "sshの公開鍵" user@host
rancher:
network:
  interfaces:
    eth0:
    address: x.x.x.x/y
    gateway: x.x.x.1
    mtu: 1500
    dhcp: false
  dns:
    nameservers:
      - y.y.y.1
      - y.y.y.2

# ホスト network 設定変更

sudo ros config set rancher.network.interfaces.eth1.address 1.1.1.1/24
sudo system-docker restart network

# nfs mount

amazon EFSじゃなくて自前のnfsを使う場合

```
NFS Server: NFS server ip address or hostname.
Export Base Directory: Exported shared directory on the NFS server.
NFS Version: The NFS version to use, current used version is 4.
Mount Option: Comma delimited list of default mount options, for example: ‘proto=udp’. Do not specify nfsvers option, it will be ignored
```

## volumeの設定

  • インフラストラクチャ - ストレージ - ボリュームを追加
  • 名前を適当に入力: nfs exportディレクトリのサブディレクトリとして作成される
  • "test" とすると nfs-server:/path/to/export/test でmountされる
  • 作成した段階ではinactive状態
  • インフラストラクチャ - コンテナ
  • ボリュームタブ 作成したtestをコンテナの/path/to/mount でmountしたい場合
  • test:/path/to/mount
  • nfsボリューム作ってない場合に↑をやると、localにtest というvolumeできてしまうので注意


# コンテナnetwork

  • コンテナ作成時のネットワークはデフォルトで"管理" 10.42.0.1/16 ? (英語だとmanaged)
  • 基本的には管理で良い
  • ホスト間でipsec貼られているのでホストに依存せずコンテナ間で疎通可能
  • ネットワーク: ホスト にするとコンテナホストとinterface状態になる
  • eth0、eth1、docker0 など全て引き継ぐ


## network 分離

Network Policy Manager カタログをデプロイすれば、サービス内、スタック内では許可、その他は拒否、というような設定が可能。

ちなみにスタックから起動せず、インフラストラクチャ - コンテナから起動したコンテナはどのスタックにも紐づかないので
"その他: 拒否" にしている場合はどのコンテナ間とも疎通は不可となる。

big-ip irule memo

bigip

httpとhttpsのpoolをひとつのiruleで処理する

例えば
example.com-http
example.com-https
のようなpoolがある場合

CLIENT_ACCEPTEDではTCP::local_portでportが判別できるので 

when CLIENT_ACCEPTED {
  switch -exact [TCP::local_port] {
    80  {  set pool_service "http"   }
    443 {  set pool_service "https"  }
  }
  set pool_prefix "example.com-"
  if ( # 何か条件分岐 ) {
    pool $pool_prefix$pool_service
  }
}

とすればiruleまとめられる

  • irule

pool hogehoge-pool
などを書いた場合、そのpoolが存在していないと構文エラーとなり
iruleを保存できない

ただし、変数などを定義して

set hogehoge "hogehoge-pool"
pool $hogehoge

とした場合はiruleは保存できるか、そのiruleが実行された際にエラーとなり、
iruleはそこで中断する。

set hogehoge "hogehoge-pool"
if { [HTTP::uri] starts_with "/hoge/" } {
  pool $hogehoge
  log local0.info "wryyyyyyyy"
}

hogehoge-poolがない場合、pool $hogehoge の時点でエラーになるため、
log local0.info は実行されずログにwryyyyyyyと出ない。

HTTP_RESPONSE

HTTP::redirect でredirectする場合は
HTTP::header insertなどを書いても無視される

irule の処理を終わらせる

1つのirule内の処理を終える場合
return

iruleが複数ファイルに分かれている場合に、
同じeventの処理を終える場合
event disable

例えば
virtualserverに

  • irule1
  • irule2

が適用されていて、HTTP_REQUESTで書かれているとする。
普通に適用すると、irule1の内容のあと、irule2も評価されるけど、
特定の条件があった場合には、irule1でHTTP_REQUESTを終えたい場合、
irule1内にevent disable
と書く

big-ip Web Accelerationでcache

bigip

httpコンテンツcacheする場合、だいたいvarnishとかnginx、apacheでやるし、
最近だとCDNもあったりするので、機能としてあるのは知ってたけど使わなかった機能。

とはいえ突発的なアクセスがきて、急に構成変更ができない場合にさくっとできるように調べて見た。

とりあえずまとめ

  • 要http profile
  • cacheはwebacceleration profile毎に個別
  • hostヘッダによっても異なる

f5 document

Local Traffic - Virtual Servers - Profiles - Services - Web Acceleration

defaultのprofileはいぢりだくないので、webaccelerationをparent profile として新規にprofile 作成

webacceleration-test

テスト

2 vip (4 virtualserver)に同一のprofileを適用してテスト

アクセスするとランダムな値を返すアプリを用意

1. 192.168.0.11:80
2. 192.168.0.11:443
3. 192.168.0.12:80
4. 192.168.0.12:443

1と2で同じキャッシュ、3と4で同じキャッシュが返ってきた。

virtualhost

hostsに

192.168.0.11 a.example.com b.example.com

とかいて

にアクセスすると異なるキャッシュが返ってきた。

さらにこのキャッシュが残っている状態で

192.168.0.12 a.example.com b.example.com

に書き換えて192.168.0.12のサーバにアクセスすると

にアクセスすると、↑と同じキャッシュが返ってきた。
(もしくは curl 192.168.0.12 -H 'host: a.example.com')

というわけで、同一webacceleration profileで
hostヘッダをkeyとしてキャッシュを使い分けてるみたい。
まあ、普通にインターネット上に公開している場合、異なるサーバ間で
hostヘッダが同じになることはないので気にしなくてよいかもしれないけど
hostヘッダ偽装により想定外のコンテンツが返る可能性があるので、
virtualserverごとにprofileはわけたほうが無難

sysstat (sadc)にTCP/IPの統計を追加する

linux

sar -n TCP、-n IPなどでTCP/IPの統計も見たい場合sadcに"-S SNMP"オプション追加が必要

man sar

With the TCP keyword, statistics about TCPv4 network traffic are reported. Note that
TCPv4 statistics depend on sadc option "-S SNMP" to be collected. The following val-
ues are displayed (formal SNMP names between square brackets):

/etc/cron.d/sysstatで実行されている/usr/lib64/sa/sa1は内部的にsadcを実行していて、
オプションは

# grep -H SYSCONFIG_DIR /usr/lib64/sa/sa1
/usr/lib64/sa/sa1:SYSCONFIG_DIR=/etc/sysconfig
/usr/lib64/sa/sa1:[ -r ${SYSCONFIG_DIR}/sysstat ] && . ${SYSCONFIG_DIR}/sysstat

のとおり/etc/sysconfig/sysstat を読むのでここに追加する

```
SADC_OPTIONS="-S DISK -S SNMP"
```
RHEL6だと-S DISKは標準で書かれていた。