Skip to content

Instantly share code, notes, and snippets.

@lunarxlark

lunarxlark/neco_skills.md

Forked from ymmt2005/neco_skills.md
Created January 27, 2019 06:25
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save lunarxlark/8b02a08c91803660ed70db8eaf957613 to your computer and use it in GitHub Desktop.
Save lunarxlark/8b02a08c91803660ed70db8eaf957613 to your computer and use it in GitHub Desktop.
Download ZIP
Neco プロジェクトのスキルシート
Raw
neco_skills.md

Neco プロジェクトのスキルチェックシート

Neco は大量の物理サーバーを効率的に管理・運用することを目的とした開発プロジェクトです。 Kubernetes を中心に高度な自律運用の実現を目指しています。

本文書はプロジェクトに参加しているメンバーが身に着けている要素技術を並べたものです。

応募時点ですべてを身に着けている必要はありません。 社内にはチュートリアル資料が多数用意されていますので、必要に応じて学べます。

リストは以下の大項目で分類されています。

ドキュメント

Neco プロジェクトではドキュメントを非常に重視しています。 仕様書はもちろん、各種ポリシーやチュートリアル、調査資料、ADR などあらゆる場面でドキュメントを作成しています。

Markdown

ドキュメントはほぼすべて markdown 形式で書いています。

mkdocs

プロジェクトの wiki は mkdocs というツールで markdown 文書から生成されています。

PlantUML

図の類はほぼ PlantUML で記述して誰でも編集可能にしています。

Architectural Decision Records (ADR)

アーキテクチャ上の重要決定は ADR として経緯や理由がわかるよう記録を残しています。

ADR のうち、markdown で書く形式の madr を採用しています。

利用しているサービス

GitHub

Neco の成果物はほぼすべて OSS として公開しています。

CircleCI

Neco の成果物の機能テストはすべて CircleCI を使って自動化されています。 テスト以外にも、自動リリースなど各種自動化に活用しています。

  • Tutorials - .circleci/config.yml の書き方など
  • ghr - GitHub Releases にアーティファクトをリリースするツール

GCP

Neco のテストでは複数の VM が必要になるので、各自が自分専用のテスト環境を持てるよう GCP を活用しています。 GCP の利用は限定的なので、内製のチュートリアル文書に従えば十分です。

quay.io

quay.io は CoreOS 社(現在は Red Hat を経て IBM 社)のコンテナイメージレジストリの SaaS です。 サイボウズでは、CircleCI などでビルドされたコンテナイメージの登録先として利用しています。

Neco のコンテナイメージは、github.com/cybozu/neco-containers というレポジトリで一元管理されています。このレポジトリに Dockerfile があり、GitHub の pull request がマージされると CircleCI で自動的にイメージがビルドされて quay.io に登録される仕組みです。

  • quay.io/cybozu - Neco プロジェクトの成果物のコンテナイメージが多数あります

プログラミング

Neco の成果物はほぼすべて Go 言語で書かれています。 そのため Go を学ぶことは必須ですし、かなり高度な使いこなしをしています。

他の言語の必要性は薄いです。シェルスクリプトが少々ある程度。

Go

Kubernetes 周辺のコンテナ技術はほぼすべて Go で作られています。 一口に Go といってもいろいろあるので、以下のリストで必要な知識を確認してください。

  • Go 言語の基礎知識
    • A Tour of Go - やったことがなければ必ずやってください
    • Effective Go - 読んだことがなければ必ず読んでください
    • Code Review Comments - 従うべきとされている慣習です
    • Modules - Go modules で構成管理しているので一読してください
  • Go 開発ツール
    • goimports - エディタの設定で保存時に自動で goimports で整形するようにしてください
    • golint - Code Review Comments に従っているかをほぼ自動でチェックしてくれます
    • go vet - 不具合がありそうなコードを検出してくれます
  • フレームワークとライブラリ
    • context - goroutine 管理には必須の標準ライブラリです。あらゆる場面で利用しています。
    • cybozu-go/well - context を中心としたフレームワークです。チュートリアル で学んでください。
    • cybozu-go/log - ログ出力はこのフレームワークを使う規程になっています
    • cobra, pflag, viper - サブコマンドがある CLI を作る高機能ライブラリです
    • gqlgen - Go 言語用 GraphQL サーバーライブラリです
    • containers/image - コンテナイメージを操作する高機能ライブラリ

etcd クライアントプログラミング

Neco プロジェクトの成果物はほぼすべて、etcd をデータストアとして利用しています。 etcd の API は gRPC ですが、Go 向けに高機能なクライアントライブラリを提供しているので gRPC は知らなくても良いです。

下記にポインタを示しますが、watch や leader election や nested transaction といった高度なプログラミングは解説が不足しています。sabakan や CKE などの既存実装を参照して学んでください。

並列・並行プログラミング

Go 言語を使う場合、並列・並行プログラミングは避けられません。 Go は goroutine と channel で手軽さを提供してくれますが、本質的な理解がなければ容易に不具合を生みます。

以下の項目についてすべて Yes でなければ、資料を参照して勉強してください。

  • スレッドプログラミングの経験がある
  • メモリバリア命令の存在理由を説明できる
  • コンパイラのリオーダーを制御する必要性が説明できる

資料：

ネットワークプログラミング

Go は非同期ネットワークサーバーを簡単に作れるのであまりテクニックやライブラリは必要ありません。

HTTP 処理は、標準ライブラリ net/http を使います。他のライブラリは使っていません。 リクエストルーティングも手書きしています。

GraphQL サーバーの実装には前述の通り gqlgen を使っています。 REST 手書きや OpenAPI よりも簡単にスキーマファースト開発ができるので、プロジェクトの方針として今後は積極的に GraphQL の API を作っていくことにしています。

テスト

テストは実行環境の複雑さによって "single host test", "multi host test", "data center test" と分類されています。 multi host test は mtest, data center test は dctest と略称されます。

機能試験はすべて自動化しています。いわゆるテストピラミッドに従い、なるべく single host test で書き、書けないものを mtest, dctest としています。

Single host test

go test で、単独のサーバー上で実行できる試験です。ユニットテストに加えて、etcd を必要とする一部結合試験も single host test にまとめています。テスト用に以下のライブラリを使うことがあります。

他のライブラリはあまり使いません。モックを実装するときも基本的に手書きしています。 GraphQL API クライアントのテストではスキーマから gqlgen で生成したモックを使っています。

  • google/go-cmp - reflect.DeepEqual よりまともな比較をしてくれます
  • net/http/httptest - 標準の HTTP 用テストライブラリ
  • cke/sabakan/mock - GraphQL スキーマからほぼ自動生成したテストモック

Multi host test

Neco の成果物は複数のサーバーで冗長化して動作させるものが非常に多いので、冗長構成に関する機能試験は複数の VM を立てて実行しています。VM のホストとしては GCP 上で GCE の nested virtualization 機能を有効にして利用しています。

VM を立てるだけではその上の OS やホストから VM に共有したいファイルや VM 間のネットワーク構成を制御できないので、placemat というツールを自作して使っています。

テストシナリオの作成には Ginkgo と Gomega というライブラリを使っています。分散システムでは、挙動の確認に一定の時間を要することが多いのですが、「一定時間内に〇〇になるはず」というシナリオを Eventually で簡単に書くことができるためです。

Data center test

Neco は、数千台の物理機材からなるデータセンターの運用を高度に自動化するプロジェクトです。 最終的にはすべての成果物を組み合わせて構築したデータセンターが正常に稼働するかを試験する必要があります。

複数のサーバーを利用するという点では mtest と同じですが、ネットワークの複雑さが顕著に異なります。 Neco のデータセンターは最小でも 3 ラック以上から構築され、Pod や Node のルーティングは BGP で行います。また Kubernetes の Node となる物理ーサーバーは DHCP と UEFI HTTP Boot でネットワークブートされます。

この複雑なデータセンター構成を placemat で仮想的に実装するために、placemat-menu というツールを開発しています。placemat-menu は複数ラック間の BGP ルーティング処理や、自社製ネットワークブートサーバーである sabakan に登録する設定ファイルなどを、簡単な構成ファイルから自動生成します。

テストシナリオは mtest 同様 Ginkgo と Gomega で作成しています。

ネットワーク

Neco のネットワークは以下の特徴を持ちます。

  • ベンダー固有の機能を完全に排除(layer-2 拡張技術を排除)
  • ルーティングは BGP
  • コンテナ環境で必要となる広帯域低レイテンシな east-west 通信に最適化
  • データセンター内の通信もほとんど TLS で暗号化

TCP/IP

Neco は現時点では IPv6 を使っていません。Kubernetes 周辺のエコシステムが IPv6 に成熟していないためです。 TCP と IPv4, およびルーティングに関して基礎的な知識は必要となります。

BGP

BGP に詳しい人もそうでない人も以下の資料に目を通したほうが良いです。

DNS

DNS に関しても基本的な知識は必要となります。フルレゾルバ・キャッシュレゾルバとしては unbound を利用しています。

TLS / PKI

後述する Kubernetes や etcd, Vault はどれも TLS での暗号通信やクライアント認証を実装しています。 そのためデータセンター内でも認証局(Certificate Authority, CA)を用意したり、インターネット向けにサーバー証明書を発行したりする必要があります。

かなり深い知識が必要になるので、CA や CSR, X509 Certificate といった用語に疎い場合は以下の資料で学んでください。

HTTP

HTTP/1.1 を把握していれば問題ありません。Go 言語では HTTP/2 は透過的に扱えます。 サイボウズに新卒入社するエンジニアは、配属前に HTTP/1.1 の RFC を読む研修をしています。

その他

DHCP や NTP, SSH など各種ネットワークプロトコルを利用しますが、必要に応じて調べればよいです。

Kubernetes

Kubernetes による宣言的・自律的なシステム管理は Neco の中心となる構成要素です。 そのため Kubernetes は利用するだけでなく、システムの内部構成とソースコードの調査まで知らないことはないというレベルで習得する必要があります。

チームメンバーは全員 Kubernetes in Action という書籍を読んでからプロジェクトに参加しています。必要に応じてどこまでも調べる必要があるのですが、以下はこれまでに調べたりかかわってきたものの一部です。

  • kubernetes.io - 公式サイト
  • API Overview - API は各種オブジェクトの作成・変更・削除で表現する(宣言的なので)
  • CRI - kubelet がコンテナ操作をするのに必要なインタフェースを定めたもの(実装としては cri-o や containerd)
  • CNI - kubelet や Docker がコンテナ用のネットワーク操作をするインタフェースを定めたもの
    • coil - 自社製 CNI プラグイン
  • client-go - Go 言語から Kubernetes を操作するためのライブラリ

各種ミドルウェア

etcd

前述のように、etcd はデータストアとして非常に広く利用しています。 当然ながら etcdctl も多用するので、利用者としても困らないように勉強してください。

bird

BIRD は BGP をはじめとした各種ルーティングプロトコルを実装したソフトウェアです。 Neco でもすべてのサーバー上で動作しています。

Vault

Vault は HashiCorp 社製の秘密管理用ミドルウェアです。

証明書の発行機能など多彩な機能を有しており、CKE が利用しています。

Serf

Serf も HashiCorp 社製のサーバークラスタの分散管理ソフトウェアです。 Neco では物理サーバーの死活監視と、物理サーバー上で稼働しているソフトウェアの情報の流通（例えば OS のバージョンなど）に利用しています。

その他

Container Linux and Ignition

多数の物理サーバーを管理するために、ネットワークブートに最適化された Linux OS として CoreOS Container Linux を採用しています。しかしながら CoreOS 社が Red Hat (現 IBM)に買収された関係で、Container Linux はいずれ Fedora CoreOS で置き換えられる見通しです（2020年くらい？）。

Container Linux も、Fedora CoreOS も、ブート後の初期化には Ignition という仕組みを利用します。 Ignition は systemd のユニットを書くことでほぼなんでも自由にできる仕組みです。

Ignition の書き方は以下で勉強してください。

systemd

上記 Ignition や最近の Ubuntu では systemd で各種サービスを制御します。

Dockerfile

Neco ではほぼすべてのソフトウェアをコンテナとして動作させます。 そのため、イメージをビルドするルールファイルである Dockerfile を書く機会が良くあります。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment