藤井 章暢

クローバーラボ株式会社の方々と勉強会対決しました


こんにちは。
大阪スタジオ、クライアントエンジニアの藤井です。

去る3月11日(土)にクローバーラボ株式会社の皆さんと勉強会対決を行いました。
私も登壇させて頂きました!
今回はその内容と結果をレポートしていきます。

イベント名

激突! Aiming x CloverLab

ルール

4つの対戦項目(後述)で勝負を行いました。
発表の最後に参加者の皆様にAimingスタッフ・クローバーラボスタッフのどちらの内容が良かったかを投票していただき、その得票数を競うと言う内容でした。
持ち時間は1人15分でした。

対決項目(お題)

・クライアント
・インフラ
・サーバー
・開発環境

各発表内容のまとめを記載していきます。
続きを読む


rastam

敷居を下げる雑な工夫


Hello! エンジニアのラスタムです。

今回は社内コミュニケーションやチームワークを補う様々な工夫を、基盤チームの共同執筆で紹介させていただきます。キーワードは「雑」です。

〇〇という強い気持ち・〇〇という雑な気持ち

ホワイトボードの一角に「〇〇という強い気持ち」「〇〇という雑な気持ち」を書いて貼ることができるスペースがあります。

「〇〇という強い気持ち」

書く内容に制限はなくいつでも自由に書くことができます。
「『やせる!』という強い気持ち」のような個人的な雑談レベルのものや「『まず動かす』という強い気持ち」のような業務に寄ったものなど内容は様々です。

このスペースには次のようなメリットを感じています。

  • 宣言することで自分を追い込むことが出来る
  • 雑談のネタになる
  • 周りの人のことを知る、周りの人に知ってもらう機会になる

雑談レベルのものが多いのですが、そのハードルの低さのおかげで普段から書く習慣に繋がっています。
そしてその習慣があるため、たまに真面目な強い気持ちが生まれたときも気軽に書くことができます。

社内勉強会用のネタストック

チームの勉強会で発表や LT などを毎週何かしらやっているのですが、そのペースでやっていると常にネタ切れ気味になっていきます。
その対策として、ネタになりそうな話や興味があるけど調べてない技術などをストックしておくスペースがあります。(ふりかえりのタイミングでよく発生するので、ふりかえりの TRY の近く)

ネタストック

ネタがないときにそこから好きなネタを拾ったり、あるいは個人的な学習のきっかけにしたりと、勉強会を続けるための一つの工夫となっています。

GitHub 上の zatsu レポジトリー

何かをやる上でとりあえずやらないことにはやる気が出ないので
ハードルを下げるために zatsu repository が存在しています。
この記事自体もハードルを下げるためのそれです。

Issue

おやつ

色々登録されてますね。
おやつリクエストの結果、チョコ棒とここでは紹介しきれませんでしたがポテトフライ(大好き)が供給されて食いすぎて太ったので、とりあえずは今は zatsu に痩せたいと願ってます。

社内ブログ・Wiki

日々の業務で得た知見やノウハウを同僚と共有したいことがたまにあります。
しかしその中には、内容によって社外にまで公開し難いものもあります。

社内 Redmine は前から置いていますが、

  • 主にフォーマルな用途で使われていて、思いつきで書くのを遠慮してしまう
  • Textile 表記で書くという点で使い勝手があまり良くない

そこで Rendezvous という OSS ブログ兼 Wiki を社内サーバにて立ち上げました。大好きな Markdown で書けてうれしい!

Rendezvous

真面目な記事は多いですが、カジュアルなコンテンツも気軽に載せています。
そして個人日報の倉庫として使っている人もいます。

全社で使える CI サーバー(レビュー作業の自動化)

普段から GitHub でコードレビューをしていると、入力ミス・イディオムの統一などの機械的なレビューが面倒になっていきます。

文字通りですが、「機械的にできることは機械に任せよう」ということで、社内で開発した CI(継続的インテグレーション)サーバーを用いて、機械的なレビュー作業の自動化を行っています。

この取り組みによって、「本当に注力すべき箇所にレビューコストを割く」というプロダクトの品質向上の一助となっております。どうせ怒られるなら、人間からより機械だったらカドも立たなくてよいですよね ^^


勉強会・カンファレンスの運営スタッフとしての活動


大阪スタジオのwebエンジニアの富田です。

弊社の新卒採用サイトが公開されました!
私の写真も使われていて、ちょっとドキドキしてしまいます。

リクルートサイトの中でも記載されているのですが、Aimingでは社内・社外のコミュニティ活動が推奨されています。
今回は、大阪スタジオのスタッフが運営で関わっている、関西の勉強会・カンファレンスをご紹介したいと思います。


Game Creators Conferenceは、関西で最も大きなゲーム関連のカンファレンスです。

今年は、2/18に開催され、550枚のチケットが完売する盛況ぶりでした。
このカンファレンスの実行委員にエンジニアマネージャーの槙石が参加させて頂いています。

昨年の開催時は、サーバーエンジニアの山藤が登壇しエントリを書いています。


関西ゲーム勉強会は、過去11回行われている勉強会です。

前回は250名ほどご参加頂けました。
Game Creators Conferenceよりも、開発者の現場に近い部分の勉強会を目指し、参加者同士の交流を目的としています。

最近は規模が拡大し運営が大変になってきていますが、開催する毎に新しい出会いや達成感があります。

昨年、私が運営として参加した時のエントリです。


Game Gatling LTは、15名程が登壇し連続してLTを行う、若干特殊な勉強会です。

参加者は、多くのゲーム開発者の登壇を聞くことができ、登壇者もLTということであまり負担もなく、楽しんで頂いているかと思います。
過去2回開催し、いずれも好評でしたので、第3回も計画中です。

インフラエンジニアの菅野が登壇のエントリを書いています。


3/11(土)には、合同勉強会ということで、クローバーラボ株式会社様と「激突! Aiming x CloverLab」を開催します!
遊び心で対決形式になっています。どうなることか、とても楽しみです!

勉強会・カンファレンスの運営はあまり表に出ることはありませんが、コミュニティのメンバーの方々と協力しながら、開発者同士の交流のお役に立てれば!と思います。


神﨑 拓人

JenkinsとGitHubのWebhook連携の整理


Jenkins と GitHub を連携させる Webhook について

GitHub と Jenkins を連携させる機能のひとつに「Webhook」と呼ばれるものがあります。この Webhook をつかうことで、 GitHub 上で管理しているリポジトリにブランチを push したときや、新たに Pull Request を作成した時などに Jenkins のジョブを走らせるといったことができます。

しかしながら、 Jenkins や Jenkins の複数のプラグインが Webhook の機能を提供しており、どの機能がどのサービスを提供しているのかがわかりづらくなっているのが現状です。そこでこのエントリーでは、それぞれの機能でどのような特徴があり、どういった設定が必要なのかを、実際に設定を行いながら整理したいと思います。

なお使用している Jenkins のバージョンはこの記事執筆時点での Jenkins の最新バージョンの安定バージョン 2.32.3 LTS です(各プラグインのバージョンについては項目ごとに記述)。

続きを読む


Aiming飲み会 #5 を開催しました


こんにちは。エンジニアの栗本です。

先月の1月25日(水)に Aiming飲み会 #5 グラフィックエンジニア新年会 を開催いたしました。
たくさんの方にご参加いただきまして、おかげさまでLTも大変盛り上がり、大盛況のうちに開催することができました。
お忙しい中お越しくださった皆様ありがとうございます。

乾杯の様子

乾杯!

LTの様子(山納)

LTの様子(山納)

ご厚意にあずかりまして、今回の発表資料の一部を公開していただきました。以下のリンクから見ることができます。
弊社エンジニアの山納: Vertex Texture Fetchの活用について
notargs様: GLSL作曲入門
柿崎様: Luaを使ったキャラクタのスクリプティング

次回のAiming飲み会は3月ごろ、デザイナーにフォーカスしたものを予定しています。
今後の情報は Aiming – connpass で公開していきますので、ご興味のある方はぜひフォローをお願いします。
改めまして、登壇者の皆様、参加者の皆様ありがとうございました。


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 について近日公開したいと思います。


s-kuroki

Ruby関西勉強会に会場を提供しました #rubykansai


大阪スタジオのwebエンジニアの黒木です。

1/14(土)に開催された第76回 Ruby関西 勉強会に大阪スタジオのセミナールームを提供しました。

Ruby関西は関西では最も歴史の古いRubyコミュニティで、現在も2ヶ月に1度勉強会が開催されています。また、主催イベントに過去6回開催されている関西Ruby会議があり、次回開催が今年の5/27(土)に予定されています

勉強会の発表内容は毎回多岐に渡っています。前回は私も発表させてもらいました(スライド)。

今回は弊社の植森が「ゲーム会社でのRuby : rails活用事例」と題しまして、AimingでRubyとRailsをどのように利用しているのかという話をさせてもらいました。

Aimingでは勉強会への会場提供を積極的に行っています(東京大阪)ので、いつでも気軽に問い合わせしてください。をはじめ、Aimingスタッフに連絡してもらってもOKです。お待ちしています。


Aiming飲み会 #5 グラフィックエンジニア新年会 を開催します!


こんにちは。エンジニアの栗本と申します。

来る1月25日(水)に Aiming飲み会 #5 グラフィックエンジニア新年会 -ちょい先のスマホグラフィックについて語る会- を開催します!
Aiming飲み会 #5 グラフィックエンジニア新年会 – connpass

Aiming飲み会とは

Aiming飲み会と言うのは勉強会のような堅い雰囲気ではなく、お酒を飲みながら比較的ラフな雰囲気でLT(LightningTalk)大会を行おうという企画で、2015年夏から不定期で開催しています。
前回の第4回ではアクセルマークさんのご厚意により会場をお借りし、WonderPlanet 社 CTO の村田知常さんをお招きしてLT大会を開催することができ、大変盛況でした。

第1回の様子

第1回LT

第4回の様子

第4回LT

第5回Aiming飲み会

第5回になります今回は
「グラフィックエンジニア新年会 -ちょい先のスマホグラフィックについて語る会-」
というテーマで開催します。
LT 登壇者としては、 notargs さん、 rita さん、弊社エンジニアの山納に加えて、Cygames の方とアカツキの方をお招きすることになりました!

会場の都合上参加者を増やすことは難しいのですが、募集はまだ行っておりますので、興味のある方はconnpassイベントページからの参加登録をお願いいたします。
スマホグラフィックのこれからが気になる方、LTを聞きながらお酒を飲みたい方は是非お越し下さい!


Unity3DのDIフレームワーク、Zenjectの紹介


はじめまして。エンジニアの石井と申します。

今回は現在担当プロジェクトで使用しているUnity(ゲームエンジン)用DIフレームワーク、Zenjectを紹介させていただきます。

Zenjectとは

https://github.com/modesttree/Zenject

ZenjectはUnity3D向けに作成された、DI(依存性の注入)フレームワークです。
Zenjectを使うことでオブジェクト間の依存関係を外部から解決することができます。
簡単になにが良いかを説明しますと、
依存オブジェクトを別の入れ物(コンテナ)に格納しておきコンテナ経由で使うことで、
コンストラクタやメソッドの引数で渡していたり、自身でnewしていたり、FindObjectしていた部分をなくすことができます。

Zenjectサンプル

Zenjectを使ってのUIイベント処理の簡単なサンプルを作っていきます。
今回はボタンが押された時のイベントを処理するサンプルです。

1.インストール

AssetStoreからか、
https://github.com/modesttree/Zenject/releases
からダウンロードしてUnityのプロジェクトにインポートしてください。

2.Contextの作成

シーン上にContextを作成します。
右クリックからScene Contextを選んでください。
Zenject_context

3.Installerの作成

コンテナへの格納(Bind)にZenjectはInstallerというスクリプトを使用します。
今回はSingletonとしてオブジェクトをBindしていきます。

シーン上にGameObjectを作成して、
下記スクリプトをAdd Componentしてください。
※直接SceneContextでも問題ありません。
Zenject_Installer

using System;
using Zenject;

public class InstallerSample : MonoInstaller<InstallerSample>
{
    public override void InstallBindings()
    {
        Container.Bind<ZenjectSample>().AsSingle();
        Container.Bind<IInitializable>().To<ZenjectSample>().AsSingle();
        Container.Bind<IDisposable>().To<ZenjectSample>().AsSingle();
    }
}

4.ContextにInstallerをアタッチ

ContextにInstallerをアタッチすることでInstallerが機能します。
SceneContextのInstallersに、作成したInstallerSampleをアタッチしてください。

Zenject_Context_Installer0

5.UIの作成

UIを作成していきます。
下記のようにボタンを2つ作成し、
Zenject_UI_hierarchyZenject_UI

それぞれ下記のようにスクリプトをAdd Componentします。
Zenject Bindingスクリプトにより、Installerに定義しなくてもBindすることができます。
Identifierを使うことで、個別にInjectすることもできます。

Zenject_UI_Parts

using UnityEngine;
using UnityEngine.UI;
using UniRx;

public class UIView : MonoBehaviour
{
    [SerializeField]
    Button button;

    [SerializeField]
    Text text;

    public IObservable<string> OnClickObservable()
    {
        return button.OnClickAsObservable().Select(_ => text.text);
    }
}

イベントの変換はUniRxを使い、Textをstringで送出します。

6.サンプルクラスの作成

サンプルクラスを作成します。
[Inject]アトリビュートにより先ほど作成したUIViewが注入されます。
IInitializable.Initializeメソッドにより初期化され、
各ボタンのClickイベント購読し、押されたらOnClickメソッドが呼ばれるようになっています。
Sceneの切り替えやゲームの終了などでContextが破棄されるタイミングでIDisposable.Disposeメソッドが呼ばれ、
購読を停止しています。

using System;
using System.Collections.Generic;
using UniRx;
using Zenject;

public class ZenjectSample : IInitializable, IDisposable
{
    [Inject]
    List<UIView> buttons;

    List<IDisposable> subscriptions = new List<IDisposable>();

    void IInitializable.Initialize()
    {
        UnityEngine.Debug.Log("Initialize");

        buttons.ForEach(button =>
        {
            subscriptions.Add(button.OnClickObservable().Subscribe(text => OnClick(text)));
        });
    }

    void OnClick(string buttonText)
    {
        UnityEngine.Debug.Log(buttonText);
    }

    public void Dispose()
    {
        subscriptions.ForEach(subscription => subscription.Dispose());
        subscriptions.Clear();

        UnityEngine.Debug.Log("Dispose");
    }
}

7.動作確認

Sceneが読み込まれる際に、Initializeメソッドが呼ばれ、
ボタンが押されるたびにボタンのTextがログに表示され、
最後にDisposeが呼ばれていることがわかります。

Zenject_log

おわりに

簡単に紹介させていただきましたが、
他にもZenjectには様々なContext、Installerが用意されていますので、
依存関係の解決でお困りの方はぜひ一度試してみてください。


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などをいくつかご紹介していきたいと思います。