菅野 明洋

第4回 Game Gatling LTに登壇してきました!


はじめに

初めての人は初めまして、前回の記事(社内でエンジニア読書会をやってみた!)見てくれてる人こんにちは!
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

今回は、2017年12月9日の土曜日に大阪で開催されました第4回 Game Gatling LTにて、スピーカーとして私と藤井が登壇させていただきましたので、レポートとしてまとめました。

GGLTとは

関西でゲーム開発に携わるエンジニア、デザイナー、プランナー等の人が集まり、ライトニングトークを行うイベントになります。

今回発表させていただいた内容について

今回の発表は、ミドルウェアの性能試験などの話になります。

■菅野明洋:我流ミドルウェア性能・障害試験の心得

■藤井章暢:仕事以外でプログラミングのモチベを上げる方法

私の発表ではミドルウェアの性能試験を中心に発表しました。今回は後進向けの教育を想定した作りにしております。
プロジェクトでミドルウェアを選定する場合、枯れていないミドルウェアを用いると情報が少ないケースが非常に多いと思います。その中で、少しでも多くのノウハウを積むための考えみたいな物をまとめてみました。ミドルウェアを適切に選定や使用できなかった場合は単純に開発・検証する以上のコストがかかるケースが多いため、きちんと精査していきたいと思います。

藤井の発表では、業務外でのプログラミング活動についての話を発表しました。
日々の情報収集などをどのように行うか、通勤途中の時間や休日をどう活かすかなどの実例の紹介になります。業務上で知識を得るのも重要ですが、課外活動や日々の行動改善で知見を得るのも重要かなと思います。
詳しくはスライドをご覧ください。

■発表中の様子

発表中の菅野

発表中の藤井

感想

今回は、登壇だけでは無く運営の参加にも挑戦してみました。
業務を行いながら並行で準備するのは大変でしたが、勉強会の裏側が見れて良い経験ができたと思います。

また、登壇については、やや時間配分を間違えて残りのページを話しきれなかったのが残念でした。次回はそのようなミスが無いようにしていきたいと思います。

最後に

GGLT運営の皆様、会場に来場した方々、登壇の機会を頂きありがとうございました。色々と面白い活動の話や、明日から実践してみようと思えるような話等が聞けて良かったです。
今後も皆様とこのような場で情報交換できると幸いです。


oguma

Aimingインフラチームを支え(てくれてい)る技術と設計(3/3)


この記事を読むのに使用する時間の目安 = 5〜10分

你好!
Magandang hapon po!
こんにちわ! インフラチームの 小熊 です。

前回 から大分時間が経ってしまいましたが、Aimingのインフラ事情をいくつか紹介したいと思います。

TL;DR

必要だと思える時にTDIでインフラ構築をするようにしています。
また、インフラのテストもCIで回すようにしています。
普段はGithubで、その結果とReview commentを見てmergeといった流れになります。
とくに新規性のある内容はありませんが、誰かの何かのヒントになればということで、Tipsなども少し載せます。

本題

TDI

TDI (Test driven infrastructure) = テスト駆動インフラストラクチャ
を指します。

インフラの「品質管理, 事故防止, 安定したリリース管理」を行うため
定義したインフラが適切に動作するかをテストしながら構築していく手法になります。

その考え方自体は古くからあり、以下のようなサイトが参考になります

前回紹介したとおり、弊社ではServerspecを使用しています。

AnsibleやKubernetes など、もともとインフラを定義するもので、さらに重ねてインフラを定義してテストを行う必要はあるのか? という議論もあると思いますが、以下の条件の際は出来る限りテストを書くようにしています。

  • private関数, local変数 のような scopeが限定的なものは基本的にテストしないが、逆にscopeが広い場合
    • Ansibleは基本的にglobal scopeになります
  • roleなどの汎用性を高くしていて組み合わせて利用している上で、それぞれのroleで依存関係もある場合
  • 全てのエラーで停止するわけではなく、楽観的なエラーハンドリングが存在する場合
    • e.g,) Ansibleだと ignore_errors, failed_whenを使っている箇所がある
  • 複数のtoolや環境を組み合わせていて、統合的なテストがしたい場合
    • e.g,) Ansible on the Vagrant, Containers + VM Instances

他にも、重要な箇所で安心感を得るために書いた方が良いときは書くようにしていて、Jenkins等のCIでテストを回すようにしています。

pipelineで全ての環境変数による設定のテストを行い、それで問題を発見した場合はmerge前にfix commit を入れるようにしています。

Serverspec Tips

基本

以下を参考にroleで分けるようにしておくと扱いやすいです。
http://serverspec.org/advanced_tips.html#how-to-use-host-specific-properties

また、一般的ではありますが環境変数で制御するようにすると汎用的に扱えて良いです。
例えば、Jenkins によるテストの場合はどうするとか、タイトルにより特別な設定があるといったこともテストができるようにした方が良いと思います。

Rakefile サンプルコード

require 'rake'
require 'rspec/core/rake_task'
require 'yaml'
require 'highline/import'
require 'json'

unless ENV['ANSIBLE']
ENV['TARGET_HOST_YML'] = ask("Enter servers.yml path (spec/env/servers.yml): ")\
  if ENV['JENKINS_SERVER_COOKIE'].nil?
end
ENV['TARGET_HOST_YML'] = 'spec/env/servers.yml'\
  if ENV['TARGET_HOST_YML'].nil? || ENV['TARGET_HOST_YML'].empty?

desc "Run serverspec to all hosts"
task :spec => 'serverspec:all'

namespace :serverspec do
  properties = YAML.load_file(ENV['TARGET_HOST_YML'])
  task :all => properties.keys.map {|key| 'serverspec:' + key.split('.')[0] }

  properties.keys.each do |key|
    msg_for_test="on Vagrant" if "#{key}" === "wordpress"
    desc "Run serverspec to #{key} #{msg_for_test}"

    RSpec::Core::RakeTask.new(key.to_sym) do |t|

      # 環境変数チェック #########

      # Setされているか検証したい環境変数
      verify_env_vars = %w[PJCODE TARGET_ENV SERVER_NAME]

      # verify_env_vars の環境変数 を使用していないServerspec roles = 環境変数Set有無の検証をしたくないrole
      no_verify_roles = %w[vuls] # このroleは上記の環境変数は使っていないから存在チェックもしない

      properties[key]['roles'].each do |role|
        no_verify_roles.each do |no_verify_role|
          if !role.include?(no_verify_role)
            verify_env_vars.each { |env_var| raise NameError, "環境変数 #{env_var} がセットされていません" if ENV[env_var].nil? }
          end
        end
      end

      ENV['TARGET_HOST'] = key
      t.pattern = 'spec/{' + properties[key]['roles'].join(',') + '}/*_spec.rb'
    end
  end

  properties.values.each do |role|
    json = JSON.load(role.to_json)
    ENV['SERVERSPEC_ROLES'] = json['roles'].to_s
  end
end

Serverspecで、あいまい(範囲)判定がしたいとき

厳密性が必要なく、あいまいな判定にしておきたいときもあると思います。

たとえば、サーバのSpecで自動的に設定される値をテストしたい場合
(e.g,  リソースが異なるサーバが数種類あるけど、計算上は全てこの範囲に収まっていれば問題ない。など)

そのようなときは以下のようにすると判定ができます。

describe command("awk '\$1~/start_servers/{ print \$3}' /etc/php-fpm.d/#{ENV['PJCODE']}.conf") do
  its('stdout.to_i') { should be_within(14).of(20) }
end

この場合、14が差分になります。
20に対して、+-14 以内が許容される という意味になります。

上記の例ですと、
下が6 までok, 上が 34 まで ok
となります。

mariadbのinnodb_buffer_pool_size を自動的に設定している場合も範囲で判定しています。

mariadb10のspec sample

# spec/mariadb_10/variables_spec.rb
require 'spec_helper'

describe command("awk '\$1~/innodb_buffer_pool_size/{ print \$3}' /etc/my.cnf") do
  its('stdout.to_i') { should_not be_within(99.9).of(100) }
end

上記の例は、should_not判定なので
俺の innodb_buffer_pool_size が 0.1 から199.9 の範囲に収まるわけはない
もっと多く割当たるはずだ
という判定になります。

ちなみに上記で、
innodb_buffer_pool_size         = 2000MB
など、MBなどの単位が入っていても問題なく判定できます。

https://ja.stackoverflow.com/questions/23703/serverspec-%E3%81%A7-%E7%AF%84%E5%9B%B2%E6%8C%87%E5%AE%9A%E3%82%92%E3%81%97%E3%81%9F%E3%81%84-rspec-%E3%81%A7%E3%81%84%E3%81%86-be-within-of-%E3%82%84-start-with

その他のテストツール: infrataster

インフラ面から見てエンドツーエンドのテストを簡単に行えるように出来るツールです。
CapybaraやSelenium のようなインフラ用のツールです。
deploy後のチェックに使ったりします。

こちらも割と多くの記事が出ていますので
細かい説明や手順は載せません。

この記事は、要所だけということで。

infratasterの設定について

通常は以下のように設定します。

Infrataster::Server.define(
  # Name of the server, this will be used in the spec files.
  :proxy,
  # IP address of the server
  '192.168.0.0/16',
  # If the server is provided by vagrant and this option is true,
  # SSH configuration to connect to this server is got from `vagrant ssh-config` command automatically.
  vagrant: true,
)

これを汎用的に使いたい場合は、同じく環境変数でハンドリングするようにしますが、設定情報はyamlでまとめておいた方が楽なので、以例えば、以下の様に環境変数 SERVER_NAME にSETするようにして、該当するYAML内の残りの設定を読み込ませるようにすると良いと思います。

spec/spec_helper.rb の例

# spec/spec_helper.rb
require 'infrataster/rspec'
require 'highline/import'
require 'yaml'

raise "Error: 環境変数 SERVER_NAME が入っていません\n\
`コマンドラインからecho $SERVER_NAME` で確認の上、`export SERVER_NAME=xxx を実行してください`\n\
e.g.) export SERVER_NAME=wordpress  # for vagrant"\
  if ENV['SERVER_NAME'].nil? || ENV['SERVER_NAME'].empty?

# Jenkinsのテストでは対話式にしない
ENV['TARGET_HOST_YML'] = ask("Enter servers.yml path (spec/env/servers.yml): ")\
  if ENV['JENKINS_SERVER_COOKIE'].nil?

ENV['TARGET_HOST_YML'] = 'spec/env/servers.yml'\
  if ENV['TARGET_HOST_YML'].nil? || ENV['TARGET_HOST_YML'].empty?

@properties = YAML.load_file(ENV['TARGET_HOST_YML'])

Infrataster::Server.define(:"#{ENV['SERVER_NAME']}") do |server|
  server.address = @properties[ENV['SERVER_NAME']]['address']
  server.vagrant = @properties[ENV['SERVER_NAME']]['vagrant']
end

spec/env/servers.yml の例

# For infrataster

example.com:
  address: '192.168.1.1/24'
  vagrant: false

# { Vagrant
wordpress:
  address: 'wordpress'
  vagrant: true

# } End of Vagrant

例えばこれで、
SERVER_NAME=wordpress bundle exec rspec
など。

こうしておくことで汎用的かつ、特定の対象をテストしやすくなります。

もちろんspec側でもその環境変数は有効に利用できます。

require 'spec_helper'

_uri = "http://#{ENV['SERVER_NAME']}/"

describe server(:"#{ENV['SERVER_NAME']}")do
  describe http(_uri) do
    it "reponse status" do
      expect(response.status).to eq(301)
    end

    it "responds with content inflated automatically" do
      expect(response.headers['content-encoding']).to be_nil
    end
  end

  describe capybara(_uri) do
    it 'shows welcome page' do
      visit '/'
      expect(page).to have_content 'WordPress へようこそ'
    end

    it 'shows sample page' do
      visit '/?page_id=2'
      expect(page).to have_content '新しく WordPress ユーザーになった方は、ダッシュボードへ行ってこのページを削除し、独自のコンテンツを含む新しいページ
  作成してください。'
    end

    it 'shows unclassified page from sample page' do
      visit '/'
      click_on '未分類'
      expect(page).to have_content 'カテゴリー: 未分類'
    end
  end
end

各ツール共通で使える値は、共通で扱える環境変数名にしておくとintegrationしやすいです。

e.g,)
export SERVER_NAME=”wordpress”
docker, k8s, ansible, serverspec, infrataster でも同じ環境変数を利用

Security check

vuls や専用ツールで定期的にチェックを入れています。

Kubernetes

最近、弊社でもKubernetesを扱うようになってきました。

Kubernetes-helmで YAML生成するのも良いと思うのですが、以下のようなsnippetツールを見つけたので、紹介させていただきます。

https://github.com/ipedrazas/kubernetes-snippets

少しは楽できるかな?と思い、使い始めたところです。

さいごに

誰かにとって少しでもお役に立てれば幸いです。
Aimingではインフラエンジニアも募集しております。
ご興味のある方がいましたら、ぜひご応募ください。


oguma

ハートビーツさんと懇親会でLTをしました ’17 06/16


どうも、こんにちわ。

SNS幽霊部員ビリティ高めなOgumaです。
AimingではインフラをAll layerで担当しています。

先日6/16に、そのインフラに関係するMSP (Management Service Provider) である
ハートビーツ さんに 数名で 遊び 懇親会に行かせていただきました。

その際に後輩の趙くんと共にLTをやらせていただきました!!!

国内 (海外は担当が異なる) の公式サイトや、それらと連動するゲーム内から呼び出されるwebView向けのサーバなどをCephFS上に載せてみた話をしました。

さすがハートビーツさんっっ!!
いつもブログ等で勉強させていただいてる高いスキルをもった方々がいらっしゃいますね。
いろんな貴重なお話をさせていただいて、大変嬉しかったです。

また、発表した資料にさすがプロと言える鋭い質問をいくつも頂けました。

例えば

  • なぜCephなのか、Glusterではなかったのか
    • Glusterの方が高速に動いたからGlusterの方を選択した前例があったとのこと

など。 (お酒が回ってて、これ以上は思い出せませんw)

資料には書かれていないことなので、ここで補足という形で
我々がCephFSを採用した理由をまとめますと以下になります。

  • 今回の場合、I/O速度を求めなくて良いようなところに使用した
    • そのように設計した & なっている (I/0が必要なところはDB関係のみ)
  • CephがOpenStackで実績が積まれていて大部分が枯れている (LTSの安定に期待が持てた)
  • CephFSを使ってみたかった
    • 使ってみたら安定していた
  •  (今回の資料には書けていないところもありますが)高速化方法が色々把握できた
  • Kubernetes のPersistent diskでも対応している
  • スケーラビリティの高い分散ストレージClusterが必要
    • webViewや、イベントのアクセスが大量に来ることがあるため
  •  我々のGluster Storage (Redhatに買収されてからRHGSになった)の利用経験、実績がない

といった点です。

その他弊社からは
アプリケーションエンジニアより、昨今注目されているPrometheus についてLTがありました。

好評の触ってみたシリーズで、最後の刺さる点を共有してくれたところも勉強になりました。

hbstudyというITインフラ業界では有名な勉強会を開催している憧れの会社/エンジニアさんがいる会社で、スキル高いなーと再認識しました。
(人気が凄くてなかなか参加できていませんが、かなり前に個人的にもhbstudyに参加したことあります)

とても貴重で楽しい体験をさせていただけたハートビーツさんに
この場を借りて、心から感謝と敬意を表させていただきます。


久保 翔太

GCE Local SSD向けのチューニング


こんにちは、インフラエンジニアの久保です。

今回は、GCE(Google Compute Engine)のLocal SSDのチューニングとベンチマーク結果についてご紹介したいと思います。

Local SSDとは

GCEではPersistent Disk(ネットワーク ディスク)、Local SSD、Cloud Storage Bucket、RAM Diskの4種類のディスクサービスを提供しています。
今回利用したLocal SSD はPersistent Disk(ネットワーク ディスク)と異なり、仮想マシンインスタンスのホストとなるサーバーに搭載されているSSDに直接接続されているため、非常に高速です。
Persistent Diskに比べて低レイテンシかつ高IOPSであるため、非常に高い性能が求められている環境においては非常に有用かと思います。
また、今回の試験では利用していないのですが、RAM Diskはメモリ上にデータを格納するため、Local SSDより高い性能が期待できます。
続きを読む


oguma

Aimingインフラチームを支え(てくれてい)る技術と設計(2/3)


この記事を読むのに使用する時間の目安 = 15〜20分

インフラチームの小熊です。
前回(弊社インフラチームが参考にして実践しているITサービスフレームワークや利用しているOSS, Tool類の紹介をさせていただきました。)から大分空いてしまいましたが、今回は、そのツールやOSSのTips をいくつかご紹介したいと思います。

tl;dr

Ansible は、vim-ansible-yaml を入れて、CI に放り込みつつ Serverspec等で TDD / TDI すれば良い感じだと思います。
その他のAnsible tips やVagrant について書きました。
良さそうなところがあったら参考にしてみてください。

Ansible Tips

構成管理ツールは、主に Ansible が扱われています。
(AnsibleでContainer操作も可能ですが、今回Containerの話はしません)

そんなAnsible のTipsや、最近Version 2.2の注意点をいくつか紹介したいと思います。

ツールの紹介

素晴らしいツールの紹介です!
すでに世間でよく出回っている情報ですので、知っている人は読み飛ばしてください。

  • vim-ansible-yaml
    • これを入れておけば、早く書けます
    • はい、私はvimmerです
  • ansible-console
    • module の単体テスト、動作確認が出来ます
      • e.g.) 例えばvagrantの場合は以下でインタラクティブシェルが起動します
        ansible-console -i .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory
        
      • 上記でインタラクティブシェルに入ってから
        help

        もしくは

        ?

        と打つとhelpが参照出来ます

      • このhelpを使うことでも簡単なansible-doc のような役割も満せます
        koguma@all (1)[f:5]$ help datadog_event
        
        Posts events to DataDog service
        Parameters:
        date_happened POSIX timestamp of the event.
        alert_type Type of alert.
        title The event title.
        text The body of the event.
        tags Comma separated list of tags to apply to the event.
        app_key Your DataDog app key.
        priority The priority of the event.
        aggregation_key An arbitrary string to use for aggregation.
        api_key Your DataDog API key.
        validate_certs If C(no), SSL certificates will not be validated. This should only be used on personally controlled sites using self-signed certificates.
        
  • ansible-doc
    • AnsibleのdocumentがCLI上で開けます
      • 私はvimやatom上で利用しています
  • ansible-playbook-debugger
    • 私は使っていませんが、一応debuggerもあります

version 2の注意点

  • 最新2.2について
    • check mode の対応が変わりました
      • always_run は deprecation となり、無くなる予定だそうです
        [DEPRECATION WARNING]: always_run is deprecated. Use check_mode = no instead..

        と出ます

      • 変わりに check_mode: no を使うようにしましょう
    • group_vars/等の読み込みが変わりました
      • .yml or .yaml の拡張子が必要になりました
      • 全てのfileに拡張子をつけるようにした方が良いようです
    • service module
      • systemd の扱いが変わりました
        • SysVinit scriptのものが起動できなくなっていました
        • 2.2 からsystemd module ができていました
      • sleep option を受け付けなくなりました
    • include の扱いが変わりました
      • include を使う上で変数の扱い方によっては、それら変数を Dynamic に読み込ませるかStaticに読み込ませるか選択が必要になりました
      • 詳細は以下を確認してください

whenで、値をまとめたOR判定をする

when: ansible_env.TARGET_ENV == 'test' or ansible_env.TARGET_ENV == 'development'

と書くのは長いので、下記の様に in を使います。

例 (testとdevelopmentを環境変数 TARGET_ENVで、受け取って判定をする。)

environment:
  - TARGET_ENV: "{{ lookup('env','TARGET_ENV') }}"
tasks:
  - debug: var=ansible_env.TARGET_ENV
    when: ansible_env.TARGET_ENV in [ 'test', 'development' ]"

動作確認 (test, developmentそして、skip判定確認のためのhogeをそれぞれ順番に環境変数TARGET_ENVに入れてdebug)

% for ENV in test development hoge;do TARGET_ENV=${ENV} vagrant provision test | grep -A 4 'TASK \[debug\]';done
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
ok: [test] => {
    "ansible_env.TARGET_ENV": "test"
}
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
ok: [test] => {
    "ansible_env.TARGET_ENV": "development"
}
TASK [debug] *******************************************************************
task path: /Users/koguma/work/repos/infra-ext/provision/ansible/playbooks/test.yml:20
skipping: [test] => {
    "changed": false,
    "skip_reason": "Conditional check failed",

TARGET_ENV=hoge だけ

    "changed": false,
    "skip_reason": "Conditional check failed",

になったので正常に判定ができています。

Testについて

  • ansible-spec というtoolが用意されています
    しかし、Ansible 以外のtoolとも連動させたインフラテストを行っていきたいので Serverspec と Infrataster を利用するように絞りました

    • Serverspec
      • TDD / TDI全般 で利用
    • Infrataster
      • deploy後のBDD で利用

これらについて細かいことは次回投稿する予定です。

必ず、Ansible でServerspecが実行されるようにしている

  • playbookに書いています。
    • post_tasks を使うと毎回 Serverspec でテストしてくれます
      これで 半ば強制的に TDI を実現するようにしています

Ansible playbookからの強制Test実行の注意点としては
事前にsshでアクセスできるようにしておく必要があります。(vagrant sshではなく)

[補足] Vagrant 側で用意されている vagrant ssh-config をplaybook側で実行し、~/.ssh/configに書き込むことも考えました。

しかし vagrant ssh-config に初期化 = ~/.ssh/config をワイプしてくれる機能がないので、各環境で用意したり考慮していくのも面倒だと思えました。 (Jenkinsなどでvm を作ったり消したりしながらテストをバンバン回していく環境など)

そこで、環境構築手順の簡略化も考慮し、Vagrantfile にssh pub auth 登録の処理を書いてしまっています。

playbooksが煩雑になるのを避ける

通常のansibleはplaybooksを直下に横並びで置くため、多くなってくると見づらくなる問題があります。
我々のチームの特定Projectでは、良いか悪いかは別としてplaybooks が煩雑にならないように playbooks dir 配下におけるようにしています。

具体的には以下のような構成です。

├── playbooks
│   ├── addusr_ssh.yml
│   ├── disable_selinux.yml
│   ├── gce-instance-provision_and_init.yml
│   ├── gce-lb-provision.yml
│   ├── instance-provision_and_init.yml
│   ├── monitoring-tool.yml
│   ├── td-agent.yml
│   ├── test.yml
│   ├── vuls.yml
│   └── wordpress.yml
├── plugins
│   └── inventory
├── roles
│   ├── add_ssh_user

# ..<snip>

通常は以下の構成になります。
https://docs.ansible.com/ansible/playbooks_best_practices.html#directory-layout

どうやっているか

  • Custom role path という機能を使っている
    • ansible.cfg に以下の設定をしています
      [defaults]
      roles_path = roles
      
  • group_vars, host_varsを対応させる

    Ansible galaxy でも落とせるようにしてあります。

    ansible-galaxy install aim-oguma.init-for-integrated

1/30追記: ansible-init-for-integrated に一部不備があったので訂正しました。

Ansibleの小ネタ

普段の運用でも、ansibleをよく使っています。
その中でちょっとしたネタ的な使い方を紹介します。

クラスタオペレーションツールとしてリソースを監視する例 (CPU使用率を表示)

[devinfra@test-festa ansible]$ ansible -i inventory all -m shell -a "sar -u ALL | awk 'NR==6,p{if(m<\$4) m=\$4} END{print m}'"
test-festa-slave2 | SUCCESS | rc=0 <<
0.44
test-festa-master | SUCCESS | rc=0 <<
0.39

test-festa-slave1 | SUCCESS | rc=0 <<
0.37

Vagrant

下記に内容を示します
具体的なcodeは纏めて記載します。

For Ansible provision

引数で各playbook 名を指定して、それで動くようにしています。
各種playbookがそのまま同じVagrantfileで利用可能なようにしています。


@vm_name = ARGV[1]

playbook = {
  :disable_selinux => "playbooks/disable_selinux.yml",
  :target => "playbooks/#{@vm_name}.yml"
}

Vagrant の高速化

virtioを使うようにしたり


    vb.customize ["modifyvm", :id, "--nictype1", "virtio"]
    vb.customize ["modifyvm", :id, "--nictype2", "virtio"]

local repositoryを使っています (ちなみにvagrant-cachierは問題起こすので現在利用停止中)

社内にLocal yum repositories を立てていて、社内いるときだけそれを使うように動的な処理を入れています。


Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

# ..

  # 社内の場合はLocal repositoryに向けて高速化する
  if Network.global_ipaddr.inhouse?
    config.vm.provision :shell, :inline => <<-EOT
      sudo sh -c "echo '#{MYCORP_LOCAL_REPO}' > #{MYCORP_LOCAL_REPOFILE}"
    EOT
  else
    config.vm.provision :shell, :inline => <<-EOT
      if [ -f #{MYCORP_LOCAL_REPOFILE} ];then
        rm -f #{MYCORP_LOCAL_REPOFILE}
        sudo yum clean all
        sudo yum repolist
      fi
    EOT
  end

Vagrantfile

Vagrant Cloud を利用しているので vagrant login はしておいてください。

このままでは動きませんが、playbookを用意したり、Vagrantfile に<>で書かれている部分を適宜設定していただければ利用出来るはずです。

最後に

こちらでのご紹介が、誰かのお役に立てれれば幸いです。

今回はここまでです。

次回は CI (Jenkins) や TDI tool (Serverspec), BDD tool (Infrataster)についてや、重要な脆弱性診断が行えるツール vuls について近日公開したいと思います。


oguma

Aimingインフラチームを支え(てくれてい)る技術と設計(1/3)


この記事を読むのに使用する時間の目安 = 15分

初めまして。
Aimingでインフラを担当している 小熊(oguma) と申します。

普段は、ウェブサイトの構築/運用管理や
東京と大阪のネットワーク設計/構築/運用管理、
backoffice toolなどのinfra/inhouse開発および
技術指導/教育やフレームワーク導入や運用設計を行なっています。

それと最近は機会が減りましたが、たまにゲームインフラ構築や
内部統制および情報システム管理や人事関連をやっています。

LLによる開発や、Infrastructure as Code、 Tuning、 Serverless、 Container、 システムの自律化関連にとても興味がある音楽と雪山が好きな酒好きです。

今日も元気に飲みにいきましょう!!

さて、本題に入りますが
今回は、その中でAiming インフラチームが
どのような業務スタイルで、どんなツールを使っているのかや、ちょっとしたTipsなどを少し紹介させていただきたいと思います。

それらを 計3回に分けて投稿します。

今回、このblogを読む上で得られる情報は以下になります。

  • この記事で得られる情報
    • AimingインフラチームのワーキングスタイルとITサービスフレームワーク
    • Aimingインフラチームの使用しているツール, OSSなどの各種情報
      • その中から一部のツールのTips
        • Ansible 2.x
        • Vagrant
        • Serverspec
        • Infrataster
        • vuls

今回は、Container や Serverless などの話はしませんが、
少しでも皆様のお役に立てる情報になれば幸いです。

利用しているツールやフレームワーク

さて、
我々は以下のようなツールやフレームワークを採用しています。

  • IT サービスフレームワーク
    • ITIL を参考にしています
      • 強いチーム、業務プロセス改善、ITサービス運用レベルの向上にはうってつけの教本ですね
  • 構成管理
    • Ansible
  • TDI (Test Driven Infrastructure)
    • TDD
      • Serverspec
    • BDD
      • Infrataster
  • 環境
    • Mac
    • Vagrant
    • Container
    • Docker (個人利用 & 一部Projectで本番環境も利用開始)
    • Kubernetes
    • AWS
    • GCP
    • GMOアプリクラウド
    • IDCF
  • コード管理/ CodeReview
    • Github
    • Gerrit
  • 監視 / 解析
    • Mackerel
    • NewRelic
    • Cacti
    • Nagios
    • Zabbix
    • Datadog
      • 最近導入を開始
  • 脆弱性検査
    • Vuls
    •  (app検査は別途やっています)
  • CI
    • Jenkins
  • Integration / ChatOps
    • Slack

検証や個人利用を含めますと他にもありますが、チーム内ではだいたい上記を利用させていただいています。
そして、この場を借りて作成者に心からの敬意を表します。

[DevOps] Infrastructure as Code / Configuration as Code と 品質管理 / TDI

弊社でも
CodeでInfraを管理する
という業務を主体としています。

インフラ自体の品質管理も考慮していて、
テスト = Test Driven Infrastructure (TDI: これについては後ほど説明をします。) も、行うようにしています。

以下の記事が大変参考になり、強く共感しました。

Ito naoyaさんの Infrastructure as Code
https://speakerdeck.com/naoya/infrastructure-as-code
あるべき姿をコードにする、自動化するだけではない まさに構成管理の本質を捉えた言葉だと思っています。

このインフラを定義/宣言するやり方/捉え方は、現在のDockerでもInfraKit でReleaseされているものが近い思想に見えます。(InfraKitは、Docker for AWS/Azule からの流れとのこと)
https://blog.docker.com/2016/10/introducing-infrakit-an-open-source-toolkit-for-declarative-infrastructure/
https://github.com/docker/infrakit/blob/master/README.md
http://qiita.com/yamamoto-febc/items/2cd260ba956e1a3da78e

ちなみに Consul 等のClusterでも同じことが行えます。(Infrakitほど楽にできるかどうかは別として)
このあたりは目指している方向が同じと言えそうです。 (システムの自律化, NoOps)
期待しています。

CodeReview

重ねますが、品質管理/変更管理/リリース管理 は常に意識していて
我々も日々CodeReviewを行っています。

_WIP__Ansible2_2_support_by_aim-oguma_·_Pull_Request__412_·_aiming_infra-ext

私たちは新卒1年目から積極的にDevOps, CodeReviewに参加させています。
CodeReviewは、本当に素晴らしいと思います。

Banners_and_Alerts_と__Ansible_severspecでカーネルパラメータをチェックするロールの作成_by_sycho21_·_Pull_Request__326_·_aiming_infra-ext

合理的かつ、安全性や品質が上がり、スキルも全体的に上がるなど
チーム全体どころか会社全体どころか社会的にも良いことだらけです。

他社のインフラ関連のエンジニアで
CodeReviewを取り入れている会社は多々ありますが、
もし まだCodeReview を取り入れていないインフラチームがありましたら、ぜひ Github-Flow で取り入れることを強くオススメします。

AimingInfraStudy__Ansible編_Vol-1_

今回はここまでです。

次回は少し技術よりの話にして
Ansible の Tips, 最新版2.2の注意点、
VagrantのTipsなどをいくつかご紹介していきたいと思います。


菅野 明洋

第2回 Game Gatling LTに登壇してきました!


はじめに

初めての人は初めまして、前回の記事(まべ☆てっく vol.1に登壇してきました!)見てくれてる人こんにちは!
大阪スタジオ インフラチームの菅野明洋です。
業務では、大阪スタジオのサービスインフラを担当させていただいております。

今回は、2016年10月2日の日曜日に大阪で開催されました第2回 Game Gatling LTにて、スピーカーとして私と藤井が登壇させていただきましたので、レポートとしてまとめました。

GGLTとは

関西でゲーム開発に携わるエンジニア、デザイナー、プランナー等の人が集まり、ライトニングトークを行うイベントになります。

今回発表させていただいた内容について

今回の発表は、剣と魔法のログレス いにしえの女神で使われている技術やノウハウの話になります。

■菅野明洋:スマホ版ログレスでグローバル展開を想定したサーバ構築をAnsibleで試してみた話

■藤井章暢:スマホ版ログレスにポストエフェクトを組み込んだ話


私の方ではAnsibleでの設定例を中心に発表しております。
Ansibleとなりますと、色んな書籍やブログ等でベストプラクティスや使用方法が記載されていると思いますが、今回の発表ではグローバル展開を想定した際に、どのように工夫をしたのかをまとめました。
グローバル展開を行ったとしても、サーバの構成が一切変わらないとなれば特に悩む必要はないのですが、現地のインフラ事情や新規実装を行うとなると日本版と全く同じサーバ構成と言うわけにはいかないケースもあると思います。
構成を国やデータセンター毎の差分を管理を行い、各地で行った改善内容を別の地域へ反映するなど相互的に良い事を取り込み合うことが出来たら良いかなと思いました。

藤井の発表では、クライアントにポストエフェクトを導入した話になります。
戦闘中のシーンに合わせて放射線状にブラー処理を入れ、従来の戦闘シーンをより迫力のあるシーンにしています。詳しくはスライドをご覧ください。

■発表中の様子

2016102402

発表中の菅野

2016102401

発表中の藤井

感想

LTとなりますと、「あれもこれも話したい。でも時間がない」といった葛藤があります。
ベースとなる発表資料は一週間から数日前には完成していたのですが、発表直前までスライドの編集したり脳内練習したり等、発表直前まで調整していました。

結果的には、一回目のドラがなったラスト1分前で私の喋りがスピードアップし、制限時間の終了を表すドラと同時に「ご静聴ありがとうございました」と言う形になりました(ギリギリセーフ?)。

最後に

GGLT運営の皆様、会場に来場した方々、登壇の機会を頂きありがとうございました。
とても貴重な経験をさせていただくことができました。