GitLab Meetup Tokyo #8: GitLab 11.0記念
2018/7/13に開催されたGitLab Meetup Tokyoに参加させて頂きましたので、簡単なレポートにまとめてみました。
GitLab JP コミュニティとは
Git/DevOpsツールチェーンプラットフォーム「GitLab」についての日本コミュニティで、イベントを定期的に開催していきます。
6月の#movingtogitlabでGitLabを知ったという方からGitLabをフル活用してDevOpsしているエンジニアまでどなたもご参加いただけます。
唯一無二の製品であるGitLabを導入していきたい、GitLabをもっと活用していきたい、という方に最適です。
対象参加者
- Gitを使い始めたい、Git環境を整備したい
- GitHubやBitbucketのツールを使っているが、代替品を検討している
- GitHubとその他のCI/CD・Container Registry・モニタリングツールを使っているが、一元化していきたい
- Kubernetesクラスタの構築に悩んでいる
- Prometheusでのモニタリングを使ってみたい
- DevOpsを極めていきたい
- GitLabで何ができるのか知りたい
- GitLabをもっと使いこなしたい
- GitLabコミュニティや開発に携わりたい
- 業務またはプライベートでGitリポジトリの管理ツールを探している
「GitLab 11.0 and 11.x」(@tnir)
2018/6/22にGitLab v11.0がリリースされました。どんな機能がリリースされたのか、紹介をして頂きます。
AutoDevOps機能のご紹介
Code to Production、3 Easy stepsの機能
今回やっとBETA版からGAになりました。自分は以前から結構いじっていますが、ほとんどのユーザはまだなのではないかと思います。
AutoDevOpsとはDockerfileや.gitlab-ci.ymlを書かなくても全自動でビルド、テスト、デプロイを実現してくれる機能です。
合計12の機能があります。
- Auto Build
- Auto Test
- Auto Code Quality
- Auto SAST
- Auto Dep scanning
- Auto license management
- Auto Container scanning
- Auto Review Apps
- Auto DAST
- Auto Deploy
- Auto browser perf teting
- Auto monitoring
注意：EES、EEP、EEUのみの機能もあります。
具体的にどう動くかというと、Gitレポジトリからどの言語か判別し、それに対応できるAutoDevOps機能をCIパイプラインで実行を行います。
簡単に言えば豊富な.gitlab-ci.ymlテンプレートになっています。
前提
- KubernetesへするのでプロジェクトレベルでKubernetesとの連携を有効にする必要がある
- GitレポジトリにDockerfileがあること
競合者はいるか？
- Azure DevOps Projects （現時点でベータ版、無料）
- weaveworks Weave Cloud （一部OSS、商用）
評価
大分安定してきたがまだ改善の余地がたくさんあるとのことです。
今後期待したい改良
- GKE以外のKubernetesクラスタ作成
- Kubernetes RBAC
Web IDE機能紹介
自分のコンピュータにGit CloneしなくてもGitLabのWEB GUI上でファイル編集したり、コミットしたり、マージリクエストまで作れる機能です。
Squash and Merge機能がCEにやってきた
要望が多かったもので、喜んでくれる開発者が多いでしょう。
LFS対応
GitHubからインポートする際、LFSがついにインポートされるようにらりました。これも多くのお客様から望まれていました。
Bootstrap 3 -> 4
エンドユーザーからあまり影響はない（はず）の変更ですが、GitLab開発に関わっているメンバーの中で多いなマイルストーンだそうです。
JUnit XML テスト結果表示
JenkinsプラグインのようにJUnit XMLと連携できれようになりました。これの多くのユーザが喜ぶのではないと思います。
Shota Ito GitLabの社内活用TIPSのご紹介 (@st_1t)
以下のテーマで話して頂きました。
- ああしておけばよかった編
- この機能欲しかった編
- こんなところにこんなものがあったんだ編
GitLab Groupの構造編
メンバーのアクセス付与と管理が複雑になりがちですので、GroupとProjectをどう分けて管理していくか、という悩みがありました。
結局、チーム単位にGroupと作っておけばよかったと振り返ります。
権限の分離編
Masterブランチにマージ権限がないはずなのにマージができてしまった？！
管理者とユーザ兼任のメンバーなら、アカウントを２つ用意せよ、とアドバイスしています。
Issue Templateを使おう
- 作業依頼用
- アーキテクチャ決定経緯の記録用
- 振り返り用（GitLab社のメンバーもそうしているそうで、テンプレートも公開されている）
Group配下の全プロジェクトのIssueをカンバンで見る
https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards
v10.6よりCEで利用ようになりました。
GitLab Runnerの時間指定実行
https://docs.gitlab.com/ce/user/project/pipelines/schedules.html
これはいいですね、Jenkinsが完全に不要になります。
gitlab-ci.ymlのAnchorを使う
同じようなステップが複数のプロジェクトで使われる場合、共通化することによってメンテが大分楽になるとのことです。
メンテナンスの通知機能
エンドユーザには嬉しい機能です。
GitLabハンドブックを読んで見る
透明性を追求するGitLabは採用ポリシー、各チームのオペレーションや行動、GitLab.comのアーキテクチャについてまで公開されていますので読んでおくと面白いです。
「Gitlab APIのちょっと変わった使い方」 (@xzjia)
GitLab APIの少し変わった活用について共有して頂きます。
課題：300人の組織で共通資材を作って、全員に配るような環境だが、変更があったらどうしたらよいか？？
- 最初は、周知して、チーム各自でupstreamからpullして変更を取り込む
- 各チームのプロジェクトでIssueを作って反映してもらう
- 各チームのプロジェクトでMerge Requestを作って、取り込んでもらう
GitLabのREST APIで３まで実現できますが、結構面倒な作業だと思った頃に、python-gitlabのAPI wrapperを発見して活用することにしました。
JSONファイルでどのファイルに対して、どの変更をして、どのブランチに対してどのようなコミットとどのマージリクエストをAPIで作るかを定義するような仕組みを作ってしまいました。
ずいぶんマニアックな使い方ですが、自分もこういうマニアックなAPIハックが大好きなので、機会があればこのwrapperでやってみたいと思いました。
「運用フリーを目指す運用管理術」 (ぐるなび 遠藤さん)
オンプレ運用の経験で苦労したこと、工夫できたことを共有して頂きます。
元々Subversionから、RhodecodeとBacklogに変わり、現在GitLabのみに統一しました。
使い始めて悩んだこと
- ロゴのインパクト
- Merge requestが終わらない
- システムを複雑にしてしまっちゃ
- I/Oが思ったよりでない → レポジトリをNFS上に配置したせいか
- reconfigureで基に戻る →
gitlab.rbのみ編集せよ
おすすめ運用TIPS
- 毎月バージョンアップすること
- オールインワン構成でも事足りる（2000ユーザ規模で4コア/16GBで十分持つ！）
工夫したこと
- バージョンアップの自動化
- 機能テストの自動化
- Group/Project作成
- Commit/Push操作、Branch/Issue作成
- Merge Request作成、Merge操作
- ELK/EFKでログ可視化
- production_log/api_jsonログ
- 50x系エラーなど
- 応答遅延/50x系エラー検知で再起動させる（Zabbix agentを利用）
運用フリーは放置ではないぞ！
- とくにDeprecationsに注意しましょう！
- 新機能をどんどん活用していきましょう
はい、写真を撮る時間はなかった（反省）
懇親会（ネットワーキング）
今回会場での飲食ができないということで暫くネットワーキングしてから、蒲田名物の餃子を狙いに外へ流れていきました。