FJCT Tech blog

富士通クラウドテクノロジーズ公式エンジニアブログです

富士通クラウドテクノロジーズ

FJCT/Tech blog

10分で出来る!ニフクラ上でニフクラ操作を簡単に自動化してみる (dockerによるニフクラCLI実行環境とサンプルコード)

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2019 の8日目の記事です。

昨日は @tunakyonn さんの 「M3DBの知見をまとめてみた」 でした。
なぜM3DB?と思ったのですが、prometheusの監視データ保存先として考えているんですね。
自分も、若くて勢いのあるプロダクトをサービスへ取り入れる際は、改変頻度やクオリティに苦労しながらも、ワクワクしながら取り組んでいます。
是非上手くいって欲しいです。

はじめに

仕事では、ITインフラストラクチャサービスの企画・設計・開発・運用を担当している @ysaotome です。

最近、サービス利用者より「 ニフクラCLI の使い方を説明して欲しい」とご相談頂く事が何度かありましたので、改めてPhotonやdockerを使った簡単な使い方を纏められればと思います。

f:id:ysaotome:20191208003808p:plain

「自動化」という言葉が叫ばれて久しいですが、国内の実態として、様々な理由により中々進んでない様に感じています。要因の一つとして、いきなり高度な自動化にチャレンジして挫折してしまう。といった事が挙げられると思います。そんな要因の対策として、先ずはCLIを用いたコマンドベースで手軽に手作業の簡略化から体感してみるのは如何でしょうか。

今回は「ニフクラ上でニフクラCLI実行環境を作る」方法と「ニフクラCLIを使った自動化サンプル」をステップ・バイ・ステップで紹介出来ればと思います。
特に躓かなければ10分程度でニフクラCLIが実行出来る様になります。

  • 本記事は 2019/12/07記載時点の情報です。

構築環境

実行環境としてdockerホストとdockerイメージを利用します。
※環境構築してCLI実行するだけならば、特にdocker自体の知識は不要です。

ニフクラ上でニフクラCLI実行環境を作る

ニフクラコントロールパネルへログイン

VMware Photon 3.0イメージでサーバーを作成

  • 「コンピューティング」の左メニューから「サーバー」を選択し「サーバー作成」ボタンを押下

    f:id:ysaotome:20191208004611p:plain
    「サーバー作成」を押下

  • 「サーバー作成」ウィザードの「01 イメージ選択」にて、検索ボックスに photon os 3.0 と入力して表示される「VMware Photon OS 3.0」を選択

    f:id:ysaotome:20191207212355p:plain
    VMware Photon OS 3.0イメージを選択

  • 「サーバー作成」ウィザードの「02 サーバータイプ選択」にて、配備する「ゾーン」を選択、タイプは「c-small」を選択

    • ゾーンは特に拘り等無ければ、現在は east-11 か east-12 へ作成すると良い。
    • e-miniでも良いが、c-smallの方がストレス無く実行出来ます。
      f:id:ysaotome:20191207220134p:plain
      配備するゾーンとタイプを選択
  • 「サーバー作成」ウィザードの「03 サーバー設定」にて、「サーバー名」に clitest 、「メモ」に NIFCLOUD CLI TEST を入力、「料金プラン」は 従量 を選択、「SSHキー」と「ファイアウォール」は必要に応じて新規作成(作成時はそれぞれウィザード画面内で「SSHキー作成」「ファイアウォールルール作成」を忘れずに押下する事)、「ネットワーク」は特似変更せず、「確認」ボタンを押下

    • ファイアウォールは「INルール」で SSH (22/TCP)が開いていれば必要十分
    • ここで作成してダウンロードされる [SSHキー名]_private.pem というキーファイルと、設定した パスフレーズ は接続時に利用するので記憶しておきます

f:id:ysaotome:20191207221819p:plain
SSHキーとファイアウォールも必要に応じて作成

  • 「サーバー作成」ウィザードの「04 確認」にて、内容に問題無い事を確認したら、「作成する」ボタンを押下

    f:id:ysaotome:20191207222538p:plain
    作成するサーバーの最終確認

  • サーバー作成が開始されます。

    • 作成するゾーンによりますが、2~3分程度で作成されます。
      f:id:ysaotome:20191207222936p:plain
      VMware Photon 3.0がセットアップされたサーバーを作成中
  • サーバー作成後の情報を確認

    • サーバーに割り当てられたグローバルIPアドレスを確認(キャプチャ上マスクしていますが、 27.133.xxx.xxx となっている所です)
      f:id:ysaotome:20191207223640p:plain
      サーバー作成後の画面

SSHクライアント(RLogin)で作成したサーバーへ接続

  • SSHクライアント(RLogin)を起動
    • 「ファイル」メニューの「サーバーに接続」から「新規」を選択
    • 接続設定画面を次の通り設定
      • 「エントリー」に設定名として clitest 、「ホスト名(サーバーIPアドレス)」に先ほど確認した サーバーに割り当てられたグローバルIPアドレス(27.133.xxx.xxx) 、「ログインユーザー名」に root 、 「ユーザー認証の方式によりパスワード or パスフレーズ」に SSHキー作成時の パスフレーズ を入力
      • SSH認証鍵」ボタンを押下して、SSHキー作成時にダウンロードされた [SSHキー名]_private.pem ファイルを選択
      • 全て選択したら「OK」を押下して保存
        f:id:ysaotome:20191207224300p:plain
        VMware Photon 3.0へ接続する設定を入力
    • 「Server Select」画面で「clitest」を選択して「OK」を押下
    • 最初の接続時のみ「公開鍵の確認」画面が表示されるので、内容に問題なければ「接続する」を押下
      • 内容の確認方法は気になる人は別途調べると良いです
        f:id:ysaotome:20191207225528p:plain
        公開鍵の確認
  • 設定に問題無ければログインしてコマンドプロンプトが表示されます。
    f:id:ysaotome:20191207225813p:plain
    ログイン後のコマンドプロンプト

ニフクラCLI環境構築済dockerイメージを利用可能にする

  • dockerホストを利用出来る様に設定する
    • systemctl enable dockersystemctl start docker を実行してdockerを利用出来る様にします
root@photon-machine [ ~ ]# systemctl enable docker
Created symlink /etc/systemd/system/multi-user.target.wants/docker.service → /lib/systemd/system/docker.service.
root@photon-machine [ ~ ]# systemctl start docker
  • 実行確認の docker version コマンドでdockerのバージョン確認。下記の様に表示されれば問題なし。
root@photon-machine [ ~ ]# docker version
Client:
 Version:           18.06.1
 API version:       1.38
 Go version:        go1.10.7
 Git commit:        e68fc7a
 Built:             Mon Feb  4 16:35:01 2019
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.7
  Git commit:       e68fc7a
  Built:            Mon Feb  4 16:36:56 2019
  OS/Arch:          linux/amd64
  Experimental:     false
  • ニフクラコントロールパネルへ戻り、API実行に必要な「アクセスキー」と「シークレットキー」を入手する

    • ニフクラコントロールパネル上部メニューの自分のIDを押下し、メニューから「アカウント管理」を押下
      f:id:ysaotome:20191207230537p:plain
      アカウント管理を表示する
    • 自分のアカウントを押下して「アクセスキー」を表示してメモ
      f:id:ysaotome:20191207230749p:plain
      アクセスキー表示
    • さらに自分のアカウント枠内の「表示」ボタンを押下して「シークレットアクセスキー」を表示してメモ
      f:id:ysaotome:20191207231128p:plain
      シークレットアクセスキー表示
  • SSHクライアント(RLogin)へ戻りメモした「アクセスキー」と「シークレットアクセスキー」を入れた設定ファイルを作成する

  • cat コマンドにてファイル名 nifcloud-cli.env で下記内容のファイルを作成する
NIFTY_CLOUD_URL=https://jp-east-1.computing.api.nifcloud.com/api/
NIFTY_ACCESS_KEY_ID=メモした「アクセスキー」
NIFTY_SECRET_KEY=メモした「シークレットアクセスキー」
  • 実行例
root@photon-machine [ ~ ]# cat <<ENV > nifcloud-cli.env
> NIFTY_CLOUD_URL=https://jp-east-1.computing.api.nifcloud.com/api/
> NIFTY_ACCESS_KEY_ID=XXXXXXXXXXXX
> NIFTY_SECRET_KEY=XXXXXXXXXXXXXXXXXXX
> ENV
  • NIFCLOUD CLIをテストで実行してみる
    • nifty-describe-regions で利用可能なリージョン一覧を取得してみる
    • 最初の実行時のみ、dockerイメージの取得後に実行される
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-regions 
Unable to find image 'tily/niftycloud-computing-cli:latest' locally
latest: Pulling from tily/niftycloud-computing-cli
5040bd298390: Pull complete 
fce5728aad85: Pull complete 
76610ec20bf5: Pull complete 
60170fec2151: Pull complete 
e98f73de8f0d: Pull complete 
11f7af24ed9c: Pull complete 
49e2d6393f32: Pull complete 
bb9cdec9c7f3: Pull complete 
5b816da257b4: Pull complete 
c19b88db8f77: Pull complete 
040817bae98e: Pull complete 
a30bb200c4e6: Pull complete 
Digest: sha256:1740dd1d9519f2e2a04dbccb3d20c249fefcfe65a365ccc59b0c27809636e88c
Status: Downloaded newer image for tily/niftycloud-computing-cli:latest
REGION  east-1     jp-east-1.computing.api.nifcloud.com    true 
REGION  east-2     jp-east-2.computing.api.nifcloud.com    false
REGION  east-3     jp-east-3.computing.api.nifcloud.com    false
REGION  jp-east-4  jp-east-4.computing.api.nifcloud.com    false
REGION  west-1     jp-west-1.computing.api.nifcloud.com    false
  • 2回目の実行はdockerイメージの取得処理が無いのでシンプル
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-regions 
REGION  east-1     jp-east-1.computing.api.nifcloud.com    true
REGION  east-2     jp-east-2.computing.api.nifcloud.com    false
REGION  east-3     jp-east-3.computing.api.nifcloud.com    false
REGION  jp-east-4  jp-east-4.computing.api.nifcloud.com    false
REGION  west-1     jp-west-1.computing.api.nifcloud.com    false
  • 以上でニフクラCLIが利用可能になりました

ニフクラCLIを使った簡単なサンプル

  • 利用可能なCLI API一覧
  • オススメ引数
    • --headers 出力形式が表形式または区切り文字による区切り形式の場合、カラムヘッダーを出力します。

リージョン一覧を取得する

  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-regions --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-regions --headers
IdType  Name       Endpoint                              Messages  Default
REGION  east-1     jp-east-1.computing.api.nifcloud.com            false  
REGION  east-2     jp-east-2.computing.api.nifcloud.com            true   
REGION  east-3     jp-east-3.computing.api.nifcloud.com            false  
REGION  jp-east-4  jp-east-4.computing.api.nifcloud.com            false  
REGION  west-1     jp-west-1.computing.api.nifcloud.com            false 

ゾーン一覧を取得する

  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-availability-zones --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-availability-zones --headers
IdType            Name     State      Region  Messages  SecurityGroupSupported  Default
AVAILABILITYZONE  east-11  available  east-1            true                    false  
AVAILABILITYZONE  east-12  available  east-1            true                    true   
AVAILABILITYZONE  east-13  available  east-1            true                    false  
AVAILABILITYZONE  east-14  available  east-1            true                    false 

ファイアウォールグループの設定情報を取得する

  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-security-groups --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-security-groups --headers
IdType  GroupName  GroupStatus  GroupDescription  GroupRuleLimitUpdate  GroupLogLimitUpdate  GroupLogFilterNetBios  AvailabilityZone
GROUP   SSHxDB     applied      メモ         100                   1000                 false                  east-13         
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxDB     TCP         22        22      IN     CIDR        0.0.0.0/0
IdType  GroupName  GroupStatus  GroupDescription  GroupRuleLimitUpdate  GroupLogLimitUpdate  GroupLogFilterNetBios  AvailabilityZone
GROUP   SSHxWEB    applied                        100                   1000                 false                  east-13         
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxWEB    TCP         22        22      IN     CIDR        0.0.0.0/0
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxWEB    TCP         80        80      IN     CIDR        0.0.0.0/0
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxWEB    TCP         443       443     IN     CIDR        0.0.0.0/0

ファイアウォールグループ名「SSHxWEB」配下のルールを取得する

  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-security-groups --filter "group-name=SSHxWEB" --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-security-groups --filter "group-name=SSHxWEB" --headers
IdType  GroupName  GroupStatus  GroupDescription  GroupRuleLimitUpdate  GroupLogLimitUpdate  GroupLogFilterNetBios  AvailabilityZone
GROUP   SSHxWEB    applied                        100                   1000                 false                  east-13         
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxWEB    TCP         22        22      IN     CIDR        0.0.0.0/0
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxWEB    TCP         80        80      IN     CIDR        0.0.0.0/0
IdType      GroupName  IpProtocol  FromPort  ToPort  InOut  SourceType  CidrIp   
PERMISSION  SSHxWEB    TCP         443       443     IN     CIDR        0.0.0.0/0

ファイアウォールグループを新規作成する

  • ゾーン「east-13」配下に、ファイアウォールグループ名「SSHxWEB」で新規作成する
  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-create-security-group "SSHxWEB" --availability-zone "east-13"
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-create-security-group "SSHxWEB" --availability-zone "east-13"
GROUP SSHxWEB east-13

ファイアウォールグループへルールを追加する

  • ルール追加前にファイアゥオールグループを作成しておく必要があります
  • ファイアウォールグループ名「SSHxWEB」へ以下のルールを追加する
インターネット(0.0.0.0/0)からの「80/TCP(http)」「443/TCP(https)」「22/TCP(ssh)」通信許可
ファイアウォールグループ「SSHxDMZ」からの全て(ANY)の通信許可
  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol TCP --port-range 80 --in-out IN --source-subnet "0.0.0.0/0"

docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol TCP --port-range 443 --in-out IN --source-subnet "0.0.0.0/0"

docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol TCP --port-range 22 --in-out IN --source-subnet "0.0.0.0/0"

docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol ANY --in-out IN --source-group "SSHxDMZ"
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol TCP --port-range 80 --in-out IN --source-subnet "0.0.0.0/0"
GROUP  SSHxWEB
PERMISSION  SSHxWEB  TCP  80  80  IN  CIDR  0.0.0.0/0

root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol TCP --port-range 443 --in-out IN --source-subnet "0.0.0.0/0"
GROUP  SSHxWEB
PERMISSION  SSHxWEB  TCP  443  443  IN  CIDR  0.0.0.0/0

root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol TCP --port-range 22 --in-out IN --source-subnet "0.0.0.0/0"
GROUP  SSHxWEB
PERMISSION  SSHxWEB  TCP  22  22  IN  CIDR  0.0.0.0/0

root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-authorize-security-group-ingress "SSHxWEB" --protocol ANY --in-out IN --source-group "SSHxDMZ"
GROUP  SSHxWEB
PERMISSION  SSHxWEB  ANY      IN  GRPNAME  SSHxDMZ

OSイメージ一覧を取得する

  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "all" --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "all" --headers

IdType  ImageID  Name                     Owner       OwnerAlias                          State      Accessibility  ProductCodes  Architecture  ImageType  KernelId  RamdiskId  Platform  RootDeviceType  Description  Redistributable  AvailabilityZone
IMAGE   89       Ubuntu Server 16.04 LTS  niftycloud  FUJITSU CLOUD TECHNOLOGIES LIMITED  available  public                       x86_64        machine                         ubuntu    disk                         true                             
DetailDescription
                 
IdType  ImageID  Name                     Owner       OwnerAlias                          State      Accessibility  ProductCodes  Architecture  ImageType  KernelId  RamdiskId  Platform  RootDeviceType  Description  Redistributable  AvailabilityZone
IMAGE   157      Windows Server 2016 Std  niftycloud  FUJITSU CLOUD TECHNOLOGIES LIMITED  available  public                       x86_64        machine                         windows   disk                         true                             
DetailDescription
・
・
・
・

自分が作成したOSイメージ一覧を取得する

  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "self" --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "self" --headers
IMAGE   12350    CentOS5LVM  self   ニフティクラウドユーザーブログライター  available  private                      x86_64        machine                         linux     disk                         true             east-1.east-12  
IMAGE   16378    Ubuntu1310x8664  self   ニフティクラウドユーザーブログライター  available  private                      x86_64        machine                         ubuntu    disk                         true             east-1.east-13  
・
・
・
・

OSイメージを指定してサーバーを作成する

  • OSイメージを指定するため、事前に対象OSイメージの「ImageID」を取得しておく必要があります
  • SSHキーを指定するため、事前に設定するSSHキー名を取得しておく必要があります
  • プライベートなOSイメージ「Ubuntu1310x8664」からサーバーを作成する(コピーする)
    • 「Ubuntu1310x8664」の 「ImageID」を取得
    • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "self" --headers  | grep Ubuntu1310x8664
  • 実行結果例
    • 以下の実行結果からイメージ「Ubuntu1310x8664」の「ImageID」は 16378 である事が判る
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "self" --headers docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-images --owner "self" --headers  | grep Ubuntu1310x8664
IMAGE   16378    Ubuntu1310x8664  self   ニフティクラウドユーザーブログライター  available  private                      x86_64        machine                         ubuntu    disk                         true             east-1.east-13  
  • SSHキーの一覧を取得する
    • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-keypairs --headers
  • 実行結果例
    • 以下の実行結果からSSHキー名が niftycloudTest である事が判る
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-describe-keypairs --headers
IdType   KeyPair         Fingerprint                                                
KEYPAIR  niftycloudTest  88:7b:e4:19:94:6b:a7:89:91:52:6f:95:c2:00:09:6b:f0:ab:4c:57
  • 「ImageID」が 16378 のOSイメージ名 「Ubuntu1310x8664」からサーバーを作成する
    • 引数の意味
      • --instance-id 作成するサーバー名
      • --group 所属するファイアウォールグループ
      • --key 設定するSSHキー名
      • --instance-type 作成するサーバタイプ
      • --accounting-type 課金タイプ 1 (月額課金) | 2 (従量課金)
      • --availability-zone 作成するゾーン名
      • --disable-api-termination APIからのサーバー削除の可否 true (削除不可) | false (削除可)
  • コマンド
docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-run-instances "16378" --instance-id "UbuntuTest" --group "SSHxWEB" --key "niftycloudTest" --instance-type "double-large32" --accounting-type "2" --availability-zone "east-13"  --disable-api-termination "true" --headers
  • 実行結果例
root@photon-machine [ ~ ]# docker run --env-file nifcloud-cli.env --rm tily/niftycloud-computing-cli nifty-run-instances "16378" --instance-id "UbuntuTest" --group "SSHxWEB" --key "niftycloudTest" --instance-type "double-large32" --accounting-type "2" --availability-zone "east-13"  --disable-api-termination "true" --headers

IdType  GroupId
GROUP   SSHxWEB
IdType    InstanceId   ImageId          DnsName  PrivateDnsName  State    KeyName  LaunchIndex  ProductCodes  InstanceType  LaunchTime                 AvailabilityZone  KernelId  RamdiskId  MonitoringState      IpAddress  PrivateIpAddress  IpAddressV6  PrivateIpAddressV6  SubnetId  VpcId  RootDeviceType  Admin  AccountingType  IpType  PrivateIpType  Architecture  Platform
INSTANCE  UbuntuTest  Ubuntu1310x8664                           pending                                      double-large32          2014-09-12T19:34:30+09:00  east-13                                monitoring-disabled                                                                                 disk                   2               static  static         x86_64        ubuntu 

まとめ

改めて「ニフクラ上でニフクラCLI実行環境を作る」方法と「ニフクラCLIを使った自動化サンプル」をステップ・バイ・ステップで紹介させて頂きました。
最初のステップとしてコマンドラインで手作業を自動化してみるのは如何でしょうか。

また、 GitHubのニフクラプロジェクト では、より複雑な処理を自動化するためのツールを多数公開しています。 例えば nifcloud-sdk-python を利用する事で、よりプログラミングに近い形で実装する事が可能です。

スキルや実現したい事に合わせて選択為ていただければと思います。

参考資料

ニフクラウンジの紹介

f:id:yaaamaaaguuu:20190517162548p:plain
nifclounge logo

ニフクラ を提供する 富士通クラウドテクノロジーズ は、ニフクラウンジという取り組みを実施しており、この記事ではニフクラウンジの紹介と、利用フォームへの案内などをいたします。

ニフクラウンジとは

ニフクラウンジとは、ITエンジニアやクリエイターが技術力向上などを目的として開催する勉強会を対象に、当社のセミナールームを無償で貸し出す取り組みです。

ご利用していただく際は、こちらのフォームより申し込みをお願いいたします。

会場と設備について

ニフクラウンジの会場は最小1部屋30人程度から、最大4部屋をつなげることにより最大200人を収容することが可能です。 以下の写真は4部屋をつなげた状態となります。

f:id:yaaamaaaguuu:20190621131455p:plain
ニフクラウンジ 会場

会場受付では、イベントの案内を掲示する事が可能なので、ご利用の際には、勉強会を案内する印刷物を用意してください。

各部屋にはワイヤレスのマイクと、スライドを投影するプロジェクタがあります。プロジェクタはHDMIでのみ利用可能ですが、HDMIを変換するアダプタを持ち込んでいただくことで他の端子も利用することが可能です。

また勉強会をオンラインで配信するための機材はございません。オンライン配信を行いたい場合は機材を持ち込んでいただく必要があります。

会場では飲食などが可能なので、ビアバッシュ形式の勉強会や、懇親会を開催していただくことが可能となります。 ケータリングなどの主催者とは別の方が飲食物を搬入する方式も受付可能なので、利用の申込み後にご相談ください。

最寄り駅からニフクラウンジまでのまとめ

最寄り駅から弊社までの各ルートは以下のブログに記載されています。

勉強会を開催する際の注意点

ビルの都合上、正面エントランスは19:30に閉まります。それ以降の時間の入退室は通用口からとなりますのでご注意ください。

詳細について

こちらに本ブログの内容を含め詳細を記載しておりますので、ご確認ください。

www.slideshare.net

最後に

ニフクラウンジは富士通クラウドテクノロジーズが提供する、技術力向上などを目的として開催する勉強会を応援するための取り組みです。 ご利用の際は こちらのフォーム より申し込みをお願いいたします。

Engineer Task Force 2018 レポート

富士通クラウドテクノロジーズ AdventCalendar 2018 25日目です。

qiita.com

皆さまこんにちは!Merry Christmas!25日間お疲れさまでした。

最終日は、Engineer Task Force 委員長の織田がお送りします。

とみたさんの後にお送りするのはプレッシャーが半端ないです。

Engineer Task Force については、昨年の Advent Calendar の記事をご覧ください。

tech.fjct.fujitsu.com

 

この記事では、 Engineer Task Force が取り組んだ施策の中から、いくつかご紹介差し上げる形で締めくくりたいと思います。

 

エンジニアのビジョン形成に向けて

FJCT はクラウドサービスデータ・AIソリューションサービスといったサービスを内製によって提供している事業会社になります。
自らサービスを構築し世の中にバリューを提供する上で、我々は何をビジョンとし、どのようなスタンスで、何を重要視しながら働いていくのか、これを明確にする必要性があります。

まずはエンジニアのロールモデルとスキルマップでベースを構築

そのために、まずエンジニアスペシャリストのキャリアを確実なものにするため、

  • エンジニアスペシャリストの定義付け
  • クラウドエンジニア、データサイエンティストのスキルマップの定義付け
  • スペシャリスト幹部社員に求められる要件の定義

など "How" の部分を進めていきました。

12月現在でもまだ微調整を行っており、人事制度への足掛かりや調整の段階ではありますが、

  • FJCT がカバーする技術領域
  • 評価の対象となる技術
  • 評価軸や要求されるスキルの見直し体制
  • 一般クラスから幹部クラスまでに必要となるスキルとカバー範囲の定義
  • 定量化するべき評価軸と定性を維持する評価軸の議論

などが、毎週議論され、経営・幹部・人事などを中心に制度化に向けて進んでいます。

FJCT のエンジニアが実現するビジョンをエンジニアたちが掲げる

そして、最も重要な "What" の部分である、FJCT の技術ビジョン、行動哲学、行動規範を築いているのが今現在となります。

これらをどのように進めているのかは以下の通りです。

  • Engineer Task Force x 人事のワーキンググループで骨子と大方針を策定
  • 社長との会議において、提言と承認
  • 技術系幹部との事前相談での調整
  • ワーキンググループでたたき台を作成( gitlab の issue )

今後の予定として、

  • Slack でエンジニア全員が参加するチャンネルに issue を共有して叩きあげる
  • ワーキンググループで完成形を作成して経営に報告

を控えています。

これにより、我々は何を目指し、どのように振る舞い、実現に向けて何を用いて、それがどのようなプロセスで評価され、そのためにどんな課題を解決するのかが明文化される計画です。

 

続きを読む

モダンな開発・運用環境を導入するために奮闘した(している)話 2018

この記事は 富士通クラウドテクノロジーズ Advent Calendar 2018 の23日目の記事です。 体調を崩してしまって記事の仕上げが大幅に遅れてしまいました。申し訳ありません。

22日目は @heriet さんの「 KnativeのコンポーネントとCRD 」という記事でした。 2019年に向けて抑えておきたい技術Knativeの概要を抑えた記事でしたね。

はじめに

仕事では、 ニフクラ における企画・設計・開発・運営を担当している @ysaotome です。 富士通クラウドテクノロジーズ Advent Calendar 2018に参加するにあたり、一昨年から継続している「モダンな開発・運用環境を導入するために奮闘した(している)話 2nd」がその後どうなったのか?という事、で、2018年現在の状況を書きたいとおもいます。

f:id:ysaotome:20190103214951p:plain

※昨年投稿した「モダンな開発・運用環境を導入するために奮闘した(している)話 2nd」を読まれてない方は、昨年記事もご参照ください。

続きを読む

KnativeのコンポーネントとCRD

この記事は富士通クラウドテクノロジーズ Advent Calendar 2018の22日目です。 昨日は @ntoofu さんの「続・IaaS基盤をテストする環境を作る話」でした。私の場合はいい感じに使いやすいクラウド上で自動テストする環境を作るケースが多く、クラウドの機能等を使って楽ができるのですが、そのクラウド基盤向けの自動テストとなると独自にいろいろ作りこんだり、試行錯誤する場面がより多そうですね…!

はじめに

ニフクラのエンジニアリングパーツの開発・運用を担当している id:heriet です。 この記事では、Knativeを構成するコンポーネント群と、それらを構成するCRDについて紹介したいと思います。

ニフクラではエンジニアリングパーツという形でニフクラ上のシステムに組み込みやすいパーツを提供しています。たとえば、ニフクラ RDBはマネージドなDBサービスで、 ニフクラ スクリプト はサーバーレスを実現するサービスです。エンジニアリングパーツのようなサービスを実現するためには数多くの技術を取り入れる必要があるのですが、Knativeはその中で注目している技術のうちの一つです。

続きを読む

続・IaaS基盤をテストする環境を作る話

この記事は富士通クラウドテクノロジーズ Advent Calendar 2018 21日目です。

20日目は @egoa56さんの サーバログイン時にエモい画像を出してAORI駆動開発してみた話でした。個人的な思い出話で恐縮ですが、学生の頃、管理者権限を持っていた研究室の共用サーバーで、学友が利用中の疑似端末のデバイスファイルに「進捗どうですか」と書き込んでいたずらしていたこと(例: echo "進捗どうですか" > /dev/pts/XX)を思い出しました。この話を参考にすれば、より強いAORI力を得られていたと思います。(※いたずらは節度をわきまえましょう)

はじめに

本日は @ntoofu から、 「続・IaaS基盤をテストする環境を作る話」と題して、 仮想インフラ周りのテストにまつわる話をしたいと思います。 (「続」とあるように、今日の話は去年のAdvent Calendarに投稿した IaaS基盤をテストする環境を作る話 の続報も兼ねています。)

まずは、去年から取り組んでいるIaaS基盤運用にContinuous Integration (CI)の考え方を 導入しようという動きについて簡単に説明します。

現在の私の業務は、去年までに続いて今年もニフクラという IaaS型のクラウドサービスの仮想化基盤の面倒を見るのが中心です。 VMware製品を仮想化基盤に採用しているため、vCenter ServerやNSX等を扱うことが多く、 加えて基盤運用の中で必要なサーバーにはOSS製品なども利用しており (例えば、ログの保持にElasticsearchを用いるなど)、 そうした多種多様のサーバーを運用しています。

管理する台数も多いため、それらの運用は随所で自動化がなされています。 新たに手順を自動化したり、自動化のスクリプト自体を修正したりと言ったことも日常的に 行っており、比較的コーディングを行う機会は多い業務になっています。 (10日目の記事である Operation as a code 実現に向けた運用統合ライブラリの作成活動について にて紹介している取り組みなどは、スクリプトの改善の良い例です。) また、例えばスケーラビリティの問題などで、運用中にサーバーの設定を変更したり、 トラブルの再発防止のために監視項目を追加したいということもしばしば発生します。

こうした都合により、自動化スクリプトの変更や、IaaS基盤運用システムに対する変更は 日常的に必要になっています。その一方で、それらの変更にミスがあった場合、 サービス障害に結びつくことも珍しくないため、その品質についても担保しなければなりません。

しかしながら、闇雲に確認作業やレビューを増やすといった古典的なアプローチでは、 運用システムに対する変更を加えることへの負担が大きくなってしまい、

  • 変更が大きくなることで、トラブルを生むリスクが増す
  • 変更を加えられる間隔が長くなるため、改善を図ってから恩恵を受けるまでが遅くなる
  • 変更に対する工数の多さがモチベーションを下げ、細かな問題は放置されやすくなる

といったリスクがあると考えています。

そこで、 より迅速に、それでいてより安全に、システムの設定や運用自動化の改善を行いたい という思いから、CIの考え方を導入したいと画策し、去年より活動しています。 CIは、ビルド・テストを自動化することで、本流となるソースコード(一般的にmasterブランチのもの) に対する修正(変更のマージ)を、日常的に実施できるようにすることであり、 迅速かつ安全にプロダクトを改善・エンハンスするという、 まさに求めていたメリットを得られることが期待できます。

IaaS基盤のテスト環境

しかし、CIの考えを取り入れるためには、前提となる「自動ビルド・自動テスト」を実現せねばなりませんが、 実際にはテスト環境を整備する部分に大きな課題がありました。 その解決のために、Nested hypervisorを活用し、テスト環境をオンデマンドに作成できるようにしました。 (一部、去年の内容と変わっていますが、問題があってやり方を少し変えていたりするためです。)

テスト環境として元々用いられていた環境は、多くの開発者が利用している環境であり、どうしても クリーンな状態が保ちづらい状況にありました。また、hypervisor自体がテスト対象になることも あるため、環境の数に応じて物理サーバーが必要になるので環境の数自体も制約が大きい状態でした。 したがって、自動ビルドが安定して動くとも考えにくい上、自動テストを並列で実施したりすることが 出来るほどの環境の数もないような状況でした。

そこで、以下のようなアプローチでこの問題を解決しています。

Nested hypervisor

f:id:tofu_cider:20181221080035p:plain
Nested hypervisor

通常hypervisorは物理サーバーにインストールし、その上で仮想マシン(VM)を実行できるようにしますが、 VMの上にhypervisorもインストールすることは可能で、Nested hypervisorと呼ばれています。 これを利用することで、テスト環境に必要になるESXi(VMware基盤におけるhypervisor)をVMとして 柔軟に扱うことが出来ます。

Linked clone

Nested hypervisorによりhypervisorをVMとして扱えるため、 vCenter serverのような管理サーバーや後述の踏み台サーバーなどのテスト環境に必要な他のコンポーネントVMとして用意しておけば、それらVM群をまるごとClone(コピー)することで 環境をいくつでも複製できることになります。 したがって、「種」になるようなVM群を一度用意しておけば、 以降同じような環境を簡単に作成可能になります。

しかし、単純にこれを行うと、環境を増やす度に全VMのデータをコピーする必要があり、 ストレージ容量を大量に消費する上、コピー自体に時間がかかってしまいます。

そこで、Linked cloneと呼ばれる方式を利用します。Linked cloneは端的に言えばCopy on Write方式の cloneであり、実際に書き込みが発生して差分が生まれるまではCloneしてもほとんど容量を消費しません。

ネットワークの隔離

また、Cloneする方法はストレージ以外にも問題があります。 各VMIPアドレスや、Nested hypervisor上のVMMACアドレスは変化しないため、 Clone前後のVMたちが同じL2ネットワークセグメントに属することが出来ません。

f:id:tofu_cider:20181221080214p:plain
ネットワーク隔離

そこで、VM群を全て同じ物理サーバー上に配置する代わりに、 uplinkを割り当てない仮想スイッチを環境ごとに作成してVM群をそこに接続することで、 他の環境に影響を与えないネットワークを利用できます。

踏み台サーバー

単純に専用仮想スイッチだけで完結しては環境へのアクセスの手段がないため、 1台だけ環境の外と中の間を橋渡しできる踏み台サーバーを用意し、それを利用することにします。

f:id:tofu_cider:20181221080306p:plain
踏み台サーバー

踏み台サーバー上では、環境内からインターネットのリソースにアクセスするためのHTTP proxyや、 環境内で使うためのDNSサーバーを稼働させています。

また、テストやビルドのためのプログラムは環境内で実行する必要があり、それを容易に行えるように するために、Docker APIの受け口をTCPソケットで公開したDocker hostを環境内に用意しておき、 踏み台にはDNATの設定をしておくことで環境外から環境内のDocker host上でコンテナを実行できるように しています。同時に、踏み台サーバーでNFSサーバーを稼働し、環境内Docker hostと環境外の作業サーバーで マウントすることで、コンテナと間接的にファイルシステムの一部を共有できるようにしています。

ストレージ

f:id:tofu_cider:20181221080357p:plain
FreeNAS VMを利用

Nested hypervisor上で可動させるVMの利用するストレージ(データストア)は、 VMとして環境ごとに構築したFreeNASを利用することで、環境の破棄に応じて 全てまとめて削除できるようにしています。

一時期vSANも試していたのですが、冗長化のため2つのNested hypervisorで 書き込みが発生しても、最終的に同じ物理ストレージへの書き込みとなるため、 無駄が多いことが予想され、実際にそのせいだったかは定かではありませんが、 私が検証した環境ではFreeNASの領域をiSCSIマウントするほうが高速でした。

自動ビルド

環境が整備できたところで、まずは自動ビルドをすることにしました。 ここでビルドした後の環境を、ビルド済み環境として流用することで、 各種のテストを行うための環境として活用が可能になることが 期待できたため、優先的に取り組みました。

特に説明なく「ビルド」と表現しましたが、インフラ自体に対するビルドとはいわゆる構築のこと であると考えており、IaaS基盤運用システムを対象にした自動ビルドとはすなわち、 先に説明したテスト環境にIaaS基盤運用のシステムを自動構築することに他なりません。

既に、基盤運用に用いる各種サーバーの構築は Ansible によって自動化されていたため、 テスト環境内にてこのAnsibleを実行することにより、自動ビルドは実現することができました。 実際には、テスト環境用のパラメータを用意したりテスト環境固有の細かな問題を潰す必要は 出てくることがあり、サーバーの種類が多かったこともあってそれなりに手間はかかりましたが、 特別な工夫はあまりありませんでした。

f:id:tofu_cider:20181221082059p:plain
ビルド後の環境の流用

また、ビルド後には、テスト環境の作成のために種になるVM群を軒並みLinked cloneするのと同様に、 テスト環境のVM群を軒並みFull clone(実際に全てコピーする)することにしています。 これは、Full clone後のVM群をテスト環境作成の種として扱うことで、ビルド後の状態のテスト環境を 直ちに用意できるようになるためです。

自動テスト

基盤運用に必要なサーバーが構築済みのテスト環境が容易に作成できるようになったため、 これに基づいて、実際にシステムの正常性を確認するテストをする土壌が整いました。 そこで、このようなテスト環境を作成し、各種のインテグレーションテストを自動で行う取り組みも 進めています。

実際に実施している自動テストの例として、DHCPサーバー及びその関連サーバーのテストがあげられます。 ニフクラでは、ユーザーにより作成されたサーバーに対し、DHCPにより特定のアドレスを払い出すような 仕組みが存在しており、そのシステムのテストとして、DB上での割り当てどおりにサーバーにアドレスが 振られるかどうかや、ゲートウェイの情報が設定されるかを、実際にサーバーを作成した上で確認するように しました。

インフラのテスト方法

インフラの振る舞いまで含めてテストをする方法として、 私の知る限りでは一般的に定着しているものはありません。 振る舞いをテストするフレームワークというコンセプトでは Infratasterがありますが、 先に挙げたDHCPの話などになると、やはり自力で作り込まないといけない部分が 非常に大きいのではないかと思います。

そこで、今のところは以下のライブラリなどを中心に使いつつ、Pythonでテストを書いています。

  • pytest
  • pyvmomi
    • vSphereのPython SDKとして
    • vSphere上での操作が必要な場合に利用(VMの作成など)
  • fabric
    • 適当なVMなどにSSH接続してシェル上でコマンド実行するために利用
    • 実際にpingコマンドで疎通の確認をする場合などに利用
    • コマンド実行結果を使う場合、出力形式次第ではパースなどが必要となるのが大変

特にfabricを必要とするようなケースは、かなり泥臭いアプローチになりがちですが、 現状ではやむを得ないと考えています。

インフラのテストのしやすさ

また、テストコードを書きやすいソースコードとそうでないものがあるように、 インフラのテストを進める上で、設計がテストのしやすさに影響すると感じました。

具体的にあった例として、運用者への通知は通常Zabbixを経由してメールを送るようにしている一方で、 サーバー上で動くスクリプトが異常を検知すると直接メールを送るものもあり、 急遽テスト環境内にSMTPでメールを受けてREST APIで内容を確認できるソフトウェア MailHogを導入するということがありました。 全てがZabbixを経由していれば、適切にアラートが上げられるかどうかを確かめるテストのために、 SMTPサーバーに相当するコンポーネントは不要で、Zabbixだけを確認できれば良かったでしょう。

この記事で取り上げているテスト環境の構成は、VMwareアプライアンス等も含めた テスト環境が必要であるというのが背景としてありますが、 同時に、システムを構成するサーバーとサーバーの互いの連携を分割しきれないため、 それら全てをまるごとテスト環境に詰め込んでいるという側面もあります。 しかし、先の例から言えることとして、サーバー間が無節操に連携をするのではなく、 インターフェイスを統一することで、テスト環境に必要なコンポーネントを少なくすることも可能なはずです。

この考えに基づけば、テストしやすいインフラというものを設計段階から考慮すべきなのかもしれません。

今後

ここまで、出来ていることを中心に話しましたが、 以下のように出来ていないことや解決したいこともたくさんあります。

  • テストケースの充実
    • まだ自動テストの対象が限定的なため、拡充していきたい
  • ビルド及びテスト時間の短縮
    • 実際にデプロイなどを行うため、どうしても時間がかさみ、数時間のオーダーで待つこともある
  • ストレージ使用量の削減
    • Nested hypervisor上の複数のVMのdiskが詰まったFreeNAS VMをまるごとクローンするため肥大化しがち
    • Nested hypervisor自体のメモリ量が大きめであるため、起動時にswapファイルで容量を大きく奪われる

また、CIの実現の後にはContinuous Deploymentなどにも取り組み、 トイルを撲滅し運用それ自体をエンジニアリングすることを目指しているため、 まだまだやるべきことは山積していますので、来年も継続してこの活動は 推進していく予定です。また、機会があればお話したいと思います。

まとめ

  • 迅速・安全に、システムの設定や運用自動化の改善を行いたいので、CIの考え方をIaaS基盤運用に取り入れたい
  • Nested hypervisorを利用しクリーンなテスト環境を作成できるようにした
  • クリーンなテスト環境でIaaS基盤運用システムをビルドし、テストできるようにした

明日、22日目は @herietさんの「KnativeのコンポーネントとCRD」です。 今日の記事とは打って変わってServerlessの話題になりそうですね。面白そうです。

NIFCLOUD で Elastic Cloud Enterprise

この記事はFJCTアドベントカレンダー2018の19日目の記事です。
昨日は@kzmakeさんの「いくつかのWebフレームワークのベンチマークを雑にとってみた」でした。

FJCT でインフラエンジニアをしている樋口です。

普段は主に IaaS の仮想化基盤を運用をしています。 その中でログの管理には Elasticsearch を利用しています。

f:id:higc_fjct:20181218194654p:plain

今回は、ニフクラ上で Elastic Cloud Enterprise(以降、 ECE と書きます) を動かしてみました。
ECE は Elasticsearch のクラスタを簡単に管理できる SaaS である Elastic Cloud をオンプレミスやクラウド上で展開できる製品です。

マルチサイトでレプリカを取得する機能、オブジェクトストレージ上にバックアップを取るスナップショット機能や、 2.0 からの機能である性能の違うディスクを効率的に利用できる Hot Warm 構成を試したので紹介します。

f:id:higc_fjct:20181218194855p:plain
今回つくるもの

続きを読む