GitHub本社から今年もキーマンが来日。最新ロードマップを特別に公開

今年も、GitHub，Inc. 本社からソリューションエンジニアのエド・パターソン氏が来日。冒頭のセッションを担当し、GitHubが現在注力する主要な投資分野や、最新技術のロードマップ、Inner Sourceへの考え方などについて語りました。

今後リリースされる新機能については準備が整い次第、皆さまにも順次お伝えできると思いますのでぜひご期待ください。

「intra-mart開発におけるGHEの活用」

株式会社NTTデータイントラマート 開発本部 阿久沢 拓也氏

NTTデータイントラマートは、Webシステム基盤を構築するためのパッケージソフトウェア「intra-mart」の開発を始めとして、パートナーを通じての販売、導入、サービス・コンサルティングの提供を行い、1998年から現在まで、約6000社への導入実績があります。

同社の開発本部では、GitHub Enterpriseの開発環境の改善、リリース作業の効率化を進めています。パッケージの開発チームは70名前後、開発サイクルは4ヶ月間隔の年3回リリースし、パッチ、ドキュメントの更新は毎月おこなわれている状況です。現在、ソース管理は全てGitHub Enterpriseでおこなっており、リポジトリ数は1000を超え、ビルドの仕組みもJenkinsのジョブを活用して全て自動化。コミット数は19万以上、ライブラリ全体では1145万行を超えていると阿久沢氏は説明しました。

GitHub Enterprise導入以前はSubversionを使用していた同社。当時、レビューをしてもらうためには直接開発本流にコミットするしかなく、動作しない不完全なコードがコミットされる可能性があったといいます。また、ローカルではビルドが成功したのに、CI環境では失敗したり、繁忙期や作業者間でコンフリクトが頻発して並行開発がしづらかったりなどの課題もあったと阿久沢氏は打ち明けます。

2016年の終わり頃、ソースコード管理にGitHub Enterpriseの導入を決定したことで、社内物理サーバーで稼働していたビルド環境の大半をAWS上に移行することとなりました。例えば、開発者はソースコードをpushするとHookが飛んで自動でJenkinsジョブが実行し、DockerイメージをPull。AWSのECSを利用して、EC2上のDockerコンテナ内でクリーンにビルド&テストがおこなわれ、最終的にデプロイされて機能追加が完了するという流れです。

NTTデータイントラマートのGitHub EnterpriseとCIの環境

GitHub Enterpriseを2年間運用し、のべ7回の開発を回したことで、現在はブランチ運用が容易になり、開発本流に影響なく複数のFeatureブランチから気軽にコミットが可能になったといいます。また、Status Check機能によりレビューの有無、Jenkinsビルドの結果、独自チェッカーツールによる警告などが確認されて、マージする成果物の品質を担保。開発効率が大幅に向上しました。また、Pull Request機能でレビューの機会が増え、レビュー漏れも削減。シーズン間・作業者間での並行開発も格段にしやすくなったことで開発品質の向上にもつながっているということです。

また阿久沢氏は、Redmine連携、Coverity（静的解析）連携、Pythonスクリプトによる一斉自動マージなどのAPI活用手法も公開してくれました。

「Webの受託開発現場でのGHE導入と浸透プロセスについて」

株式会社フォーク 取締役 大沼 智博氏

フォークは、企業のプロモーションに関わるキャンペーンサイト、ブランドサイト構築を中心に、デザインからシステム開発まで含めたワンストップソリューションを提供する会社です。同社も以前はSubversionを利用しており、リポジトリは社内の複数のサーバーや社外の制作会社に分散した状態で管理されていました。業界標準に合わせた開発環境のモダナイゼーションや、公開時のトラブルを回避するデプロイ手法の整備、日常的なレビューを通したチーム開発文化の醸成などが課題だったと大沼氏は振り返ります。

2016年4月にGitHub Enterpriseの導入プロジェクトがスタートしました。社内に浸透させるため、GitHub.comにプライベートリポジトリを作り、自社サイトをリニューアルするタイミングでGitHub＋Jekyll（静的サイト生成ツール）に移行。これにより広報や人事もGitHubに慣れることができたといいます。また、毎年10名前後新卒社員を採用しているため、HTMLやCSSの研修成果の提出先をGitHub Enterpriseにすることで、プロジェクトに入りやすい環境づくりもおこないました。

自社サイトでGitHubに慣れる機会を作ったフォーク

同社ではWebサイトを作った後に長期運用する案件を多く抱えることが多く、既存案件をどのタイミングで移行するかが課題でしたが、移行手順をマニュアル化し、運用が落ち着いているタイミングに移行スクリプトで順次移行させていきました。

GitHub Enterpriseの導入後、感度の高い社員が積極的に導入を牽引したことで、IssueのPull Requestテンプレートに情報が足りないといったエンジニアの不満が大きく軽減したといいます。

導入から2年半ほどが経過し、現在はエンジニアを中心に110名が利用し、オーガニゼーション数は16件、リポジトリ数は約1000件にまで増加。今後は日常的にコードレビューを習慣化し、コラボレーションを活発化させるために外部パートナーの参加も検討していきたいと大沼氏は話しました。

「SIOSのInnerSourceとGitHub」

サイオステクノロジー株式会社 常務執行役員 栗原 傑享氏

栗原氏は、過去に統合開発環境のDelphi専門のユーザーフォーラムを立ち上げ、株式会社グルージェント代表取締役社長やNPOのSeasarファウンデーション理事も兼任された経験を持ち、IPA未踏ソフトウェア創造事業にも採択されたMayaaの開発を手掛けるなど、第一線のOSS開発者、Javaエンジニアとして知られています。現在は、OSSとJavaをコアテクノロジーに幅広くサービスを提供しているサイオステクノロジーの常務執行役員として活躍しています。同社は米サウスカロライナ州にも拠点を持ち、日米で緊密な国際連携による製品開発をおこなっているのも特徴です。

以前の開発環境は、10名ほどの小さな組織がサイロ化された状態で乱立していたため、リポジトリや課題管理もチームが独自に手当し、採用する言語、ライブラリ、クラウドも有償・無償が混在していたといいます。何か困ったことが起きた時は社内ではなくコミュニティに助けを求めるなど、テクノロジー企業としての一体感が不足していたと栗原氏は振り返りました。

ALM（開発管理環境）ツールを選定・構成する上でポイントとしたのが、1）利用者である技術者に人気のあるツールであること、2）セキュリティおよびコンプライアンス対応を重視すること、3）技術者のスキル向上と内外発信についてソフトウェア面からドライブできるようにすることの3つでした。

検討した結果、2018年秋にGitHub Enterpriseを採用し、SlackやJIRAなどを連携させました。それにより、ソーシャルコーディング手法の普及と技術ナレッジの内外発信を進めながら、チャットによる情報共有の自動化と、業務実行のワークスタイルを実現。SAML（シングルサインオン）/SCIM（ID情報連携）とBOTでALMツール群をクラウド上で統合しました。

また、AWS Lambda（サーバーレスのプログラミングコード実行サービス）を利用して、GitHub Enterpriseが稼働しているインスタンスのAMI（Amazon Machine Image）をデイリーでバックアップするとともに、Amazon EC2を活用しVPC-peering（Amazon Virtual Private Cloud間でトラフィックをルーティング可能にするネットワーク接続）で海外拠点と結び、github/backup-utils（GitHub純正のバックアップ／リストアツール）を利用しています。

GitHub Enterpriseを中心としたサイオステクノロジーのシステム構成

GitHub Enterpriseの運用開始から数ヶ月を経た現在、セルスホスティング運用で70アカウント程度ですが、今後は運用範囲を拡大していく予定だといいます。また、既存の課題管理ツールからのマイグレーションや、日米開発体制におけるレイテンシ改善のため、米国リージョンへのインスタンス設置や、コンプライアンス問題（ISMS対応、知財保護など）が課題だと語りました。

続いて、栗原氏はInner Sourceの価値について言及しました。Inner Sourceとは、OSSの開発スタイル・文化を社内のソフトウェア開発に適用する理念のことで、社内のサイロ化した官僚主義を壊し、開発者に自律的なコラボレーションを促します。また、既存のナレッジを複数のラインで共有するという意味でも使われます。同社はInner Sourceによって他部署で活用されたリソース（知識・経験・成果物）を並行する別の開発案件においても活用する方向で取り組んでいます。

GitHubによってPull Requestが開発され、GitHub.comが開発言語レベルでセントラルリポジトリとなっている今、著名企業が巨大な資本投下によってOSSを作っている状況だと指摘する栗原氏。OSSは使うだけでなく、作っていくことも重要だと述べ、Private SauceだったものをInner Sourceにし、それをOpen Sauceに派生させるような活動を今後もおこなっていきたいと話しました。

「Github EnterpriseとDrone.ioによるCI/CD環境の整備」

株式会社インターネットイニシアティブ クラウド本部
クラウドサービス1部 パブリックリソース1課 濵﨑 一樹氏

インターネットイニシアティブ（IIJ）は単体で社員が約2000名の会社で、クラウド、セキュリティ、ネットワーク、データセンター、SI、モバイルなどサービス範囲は非常に広く、社員の7割は技術職が占めています。GitHub Enterpriseのシート数は現在470、リポジトリ数は約8000、オーガニゼーション数は約300という状況です。濵﨑氏はパブリッククラウド（IIJ GIO）の開発を担当し、2017年からGitHub Enterpriseの管理者も担っています。同社はSubversion、GitLab/Gitorious（試験的導入）を経て、2013年にGitHub Enterpriseを導入。その後、2014年にDrone.io、2018年にMicrosoft Teams（チャット）を導入しました。

IIJはSaaSやIaaS、組み込み、回線など提供するサービスが多種多様なため、統一された開発フローが存在しません。そのため、可能な限り汎用的なツールを整備して、開発言語・ツールはプロジェクトごとに自由に選べるようにしているといいます。

国内では屈指の早さでGitHub Enterpriseを導入した同社ですが、導入当初はまだCI/CDサービスとの連携が難しく、試行錯誤していたと濵﨑氏は振り返ります。そんな中で登場したのがDrone.ioでした。Drone.ioはDockerベースのCIで、GitHub Enterpriseとの親和性も高く、Dockerコンテナ内の閉じた環境でテストを自動実行できるのがポイントだったといいます。Drone.ioを便利に使うために、イメージを保管するDocker Private Registryと、登録したイメージを管理するUIのDocker Registry Frontendをセットで提供し、申請なしで活用できるようにもしました。

IIJのDrone.ioの管理画面例

GitHub EnterpriseとDrone.ioは、導入後、社内用のブラウザ拡張のソースコードや、社内ツールとして使うためのAPIをラップしたライブラリなどを公開する場として、利用が活発になりました。社内の面識のないエンジニアからPull Requestが飛び、誰かが進んで修正し、Confluence（Wiki）上で宣伝され、社内に拡散していくといった好循環が生まれているといいます。また、コードを書かないサポート部門も、マニュアルのビルドや公開、お客様向けアナウンス文面のPull Requestによるレビューや、CIによる日本語チェックなどで活用しているようです。

しかし、申請不要で活用を進めた結果、登録しながらあまり利用していないアカウントが多数発生。維持コストもかかるため、Apache AirFlowを活用してサスペンド作業の自動化を実現しました。また、ユーザーが退職すると、そのユーザーに発行された他のアプリと連携させるためのアクセスキーが無効となり、GitHub連携も不可能になるため、GitHub Appsで人に紐付かない権限で連携設定できる機能を開発し、解決したとのことです。

今後は、特にGitの仕組みを知らない人や、バージョン管理・チケット管理の文化がない部署などを対象に、GitHub Enterpriseの使い方を解説するためのCI/CDを含めた教育用資料を作成していく予定だと語りました。

「JFrog Artifactory 導入事例紹介」

楽天株式会社 クラウドプラットフォーム部 スタックワイドリライアビリティ課
ECインフラストラクチャーグループ 古川 貴朗氏

マクニカは2018年12月に、イスラエルに本社を置くJFrog Ltdと販売店契約を締結し、DevOpsソリューション「JFrog Enterprise,Enterprise+」の提供を開始しました。JFrog社ソリューションは、世界で4600社以上の導入実績を持ち、ソフトウェアの開発からリリースまでの一連のプロセスを、継続的かつ効率的に実現することを支援します。具体的には、「JFrog Artifactory」（ソフトウェアやライブラリ、Dockerイメージなどのアーティファクトを管理）、「JFrog Xray」（アーティファクトの脆弱性のスキャン、OSSのライセンス違反の検出）、「JFrog Distribution」(ソフトウェアの配布を自動化)、「JFrog Mission Control」（JFrog製品の設定や監視、運用保守を一元管理できる管理コンソール）などの機能群で構成され、一部ソリューションは個別でもご提供しています。

今回は、楽天の古川氏がArtifact Registryの必要性と、JFrog Artifactory(ユニバーサル・アーティファクト・リポジトリ・マネージャーツール)の導入事例を紹介してくれました。

Artifact Registryとは、ソフトウェア開発の成果物を格納する場所であり、CI/CDを実現する上では不可欠な存在だと古川氏は説明します。具体的には、ソフトウェア開発において変更のコミットをGitHubにした際、GitHub側がWebhookなどでCIツールをキックすると、CIツールの中で成果物（Artifact）をビルドし、その結果をストアする先がArtifact Registryとなります。
Artifact Registryのメリットは大きく2つあります。1つは依存管理。依存関係のあるArtifactを静的に扱うことが可能になるため、ビルドの再現性が保証され、“私の端末では動くのに他の端末では動かないという問題”を防ぐことができます。また、ビルドの一貫性が保証されることで、ビルドパイプラインをシンプルに保つことができます。
もう1つはセキュリティとコンプライアンス。誰がいつpushしたのかなどの活動履歴を保存することで、認証と認可の仕組みがサポートされます。

楽天ではArtifact Registryの導入において、JFrog Artifactoryを選定しました。楽天の開発組織体制は、開発グループ、運用グループ、インフラ基盤グループの3層に分かれています。JFrog Artifactory導入以前、古川氏が管轄するチーム（運用グループ、インフラ基盤グループ）では、サーバー管理者向けのプライベートリポジトリを管理していました。一方の開発グループでは各チームで異なるアーティファクト・リポジトリ・パッケージを個別のサーバー上で活用している状況だったといいます。

そのため、人的負担や無駄なサーバーリソースの運用コストがかさむほか、野良リポジトリが発生して認証・認可の運用や履歴管理などが疎かになるなど、セキュリティ上の問題もありました。

2018年の春に、すでにJFrog Artifactoryを活用していた開発チームから運用の引き継ぎを依頼され、それをきっかけに組織全体で導入することになりました。JFrog Artifactoryを標準した理由について、古川氏は、1）世界的なデファクトスタンダードであること、2）サポートするパッケージタイプが豊富なこと、3）オンプレミスやパブリッククラウドもサポート可能なこと、4）課金がユーザー単位ではなく製品単位であることなどを挙げました。

楽天はJFrog Artifactoryを導入し成果物管理を一元化

JFrog Artifactoryの導入により、従来のアーティファクト管理の一元化が可能になったことでコストを削減したほか、外部リポジトリのミラーとして活用し、社内プロキシ問題を軽減。チームAが開発しているライブラリをチームBが利用するなど、組織を越えたコラボレーションも活発になっているといいます。

ただ、JFrog Artifactoryを運用していく中で、順調すぎるほどユーザーが増え、リポジトリ作成の依頼が頻繁に来るようになって困ったという古川氏は、TerraformやCircleCIなどを活用して、ユーザー、グループ、レポジトリなどポリシーをGitHubでコード管理する「Policy as Code with GitOps」を取り入れたと説明しました。

今後は、CI/CDにセキュリティの視点を取り入れ、より早くフィードバックループを回して安心・安全なソフトウェア開発をめざすDevSecOpsを促進していくということです。

「CircleCIで始める継続的インテグレーション」

CircleCI Japan ソリューションズエンジニア 車井 登氏

CircleCIは、ソフトウェア開発者をターゲットにより良いコードをより早くデリバリーするためのサービスを提供するため、2011年に米サンフランシスコで創業。現在は世界中に約200名の社員が在籍しています。2018年6月にCircleCI Japanが発足。車井氏は10月からソリューションズエンジニアとして参加しました。

セッションの冒頭、車井氏はCircleCIをあまり知らない方のために、GitHubとCircleCIがどのように連動し、IssueやPull Requestがどのように表示・活用できるのかを説明しました。また始め方も簡単で、CircleCIはGitHubのOAuthアプリケーションとして動作するため、ログインした状態ならGitHubとの連携設定は完了。権限がCircleCIに委譲されてリポジトリ一覧が表示されます。その後、セットアッププロジェクトを起動すると、サンプルが表示されるのでCircleCIの設定ファイル（config.yml）をリポジトリに追加した後に、Start Building機能によってCircleCIの画面からビルドを開始できる状態になります。

CircleCIのUIでPull Requestを表示

次に、車井氏はビルドの高速化に関して、3つの機能を説明しました。1つ目はワークフロー。チェックアウト→ライブラリの依存関係を解決→ビルド→テスト→デプロイという流れの中で、できる限りビルド設定（ジョブ）を分解し、ジョブ間の依存関係の定義や並列処理をおこないます。2つ目はキャッシュ。ワークフローが繰り返し実行される同一ジョブで利用される永続データを使い回すほか、同一ワークフロー内の異なるジョブ間でデータを共有します。3つ目は並列処理。例えば4並列で10個のテストを実行する場合、以前のテスト結果からどのようにテストを分割すれば4コンテナで時間が平準化されるかを計算して処理を行います。
その他、秘密情報の扱いも可能で、データベース接続のためのログイン・パスワードやクラウドへのアクセスキーなど、プロジェクトメンバーの中でも一部にしか公開したくない秘密情報はCircleCIで管理し、ビルドを回すことができるということです。

ではなぜCircleCIは高速化が可能なのか。車井氏は、1）コードがコミットされてからデプロイされるまでの時間、2）CIビルドにかかる時間、3）CIビルドが始まるまでの時間、4）マスターブランチが壊れている時間、5）ツールのメンテナンスなど開発以外にかかる時間などが短縮できるからだと説明しました。
CircleCIはGitHubと簡単に連携することが可能で、開発者が直感的に利用することができる上に、CIビルドを高速に実行するための機能を備えていると車井氏は強調しました。

「開発チームの情報共有と成長をサポート　GitHub Enterprise連携コードレビュー支援サービスSiderのご紹介」

Sider株式会社 代表取締役 角 幸一郎氏

Siderは、開発チームの情報共有と成長をサポートするGitHub連携コードレビュー支援サービスです。2019年2月にGitHub Enterprise向けSiderを正式リリースしました。

セッションの冒頭で角氏は、GitHub、CI/CD、インフラのコード化、ハードウェアの向上によって自動化できる分野は確実に高速化しているものの、人が関わるコーディング環境、特にコードレビューの領域は改善が遅れているのではないかとの懸念を示しました。コードレビューに多くの費用とリソースが使われ、1）属人的なドキュメント増大によるチーム間での理解度や熟練度のばらつき、2）レビュー待ち時間の無駄、3）同じコメントレビューの繰り返し、4）ヒューマンエラーによって発生する抜け・漏れなどが日々積み重なっているといいます。

Siderは指摘ではなく実装上の確認項目を示唆してくれるのが特徴

Siderは、独自の解析機（OSSとして公開）を持っており、プロジェクト固有のルールや歴史的経緯等をその設定ファイル（YAMLファイル）に容易に記載することが出来ます。これによりコードレビューを容易に自動化でき、抜け・漏れを防止することが可能になります。また、角氏は、一般の解析ツールのように“指摘”するのではなく、実装上の確認項目として“示唆”してくれるのも特徴だと強調しました。GitHub EnterpriseのPull Request時に自動検知し、おおむね1～3分以内に検査結果（コードレビュー）を通知します。それを元に、必要ならば修正して再度push、もしくはCloseして完了というわけです。

さらに、linterによる静的解析もサポート。ルールを書かなくてもサインアップしてリポジトリを追加すれば、一般的なlinterがGitHub EnterpriseのPull Requestに連動して検査が開始され、スタイルの統一や言語に応じたベストプラクティスを最適なUIで表示してくれると角氏は説明しました。

「Lychee RedmineとGitHubとの運用事例とちょっと耳寄り情報」

株式会社アジャイルウェア 営業 水口 崇氏

アジャイルウェアは、システム受託開発や、プロジェクト管理ツール「Lychee Redmine」の開発・販売のほか、議事録リアルタイム共有サービス「GIJI」の開発・販売なども手掛けています。今回はLychee RedmineとGitHubとの自社運用事例について語っていただきました。

Lychee Redmineは現在、導入企業が500社を超え、お客様のご要望に沿った受託開発も進めて機能追加をしながら製品を成長させています。人気のプラグインとしては、スケジュール管理の「ガントチャート」やSCRUMに対応する「チケットボード」（カンバン）、工数リソース管理の「タイムマネジメント」や「リソースマネジメント」などがあります。

アジャイルウェアでは、以前からソフトウェア開発する際のコード管理をGitHub.comでおこなってきました。その理由として、アジャイル開発を進める上での品質管理や集中できる環境、エンジニア育成など、エンジニアのための最適なレビュープロセスがあるからだと水口氏はいいます。
ただ、RedmineとGitHubを連携する上でいくつかの課題もありました。1つは、Redmineは同じサーバー内にBareリポジトリのクローンがないと連携できず手動になること。もう1つは、変更検知（push検知）が標準ではないこと。そのため、アジャイルウェアでは、Redmineはマネジメントサイドのプロジェクト管理やタスク管理、進捗管理などの見える化ツールとして限定し、リポジトリ連携はさせていませんでした。一方、GitHubはPull Requestやレビューをおこなうためのエンジニア同士のコミュニケーションツールとして、明確に割り切って運用していたといいます。
その結果、マネジメントサイドでは全体把握が直感的にしづらく、優先順位を示しづらいという課題が生じ、エンジニアサイドもタスクの優先順位がわかりづらい、チケット更新を忘れるなどの弊害が起こりました。

そこで同社は、Lychee Redmineを開発。かんばん機能のLycheeチケットボードで優先順位を手動でつけたほか、ガントチャート上で同時進行している複数のプロジェクトのマイルストーンも管理。GitHubと併用することで、マネジメントサイドでは全体把握が可能になり、進捗状況の見える化も促進。優先順位の変更が容易になりました。

Lycheeガントチャートで同時に進行する複数のプロジェクトのマイルストーンも管理

また、エンジニアサイドもRedmineをタスクの優先順位が把握しやすくなるとともに、ステータス更新も手軽になり、レビューはGitHubのUIで実行可能になったといいます。

ただ、リアルタイムに連携できない点にまだ不満があったという水口氏は、「GitHub連携プラグイン」をOSSで開発中だと明かしました。Redmine上でGitHubからリポジトリをクローンするほか、個人設定画面でGitHubのアカウントと連携設定する機能、チケット詳細画面からブランチ作成やPull Requestを生成する機能などを盛り込む予定です。水口氏は、このプラグインによってGitHubとLychee Redmineとの併用運用がシームレスになり、マネジメント側とエンジニア側との連携がより深まるだろうと強調しました。

「Macnica Private Docker Cloud」

マクニカソリューションズ株式会社 技術部 第２課 野原 峰彦

マクニカグループでは、多くの製品の技術サポート業務において、外部ソフトウェア連携や解析ツール、監視ツールなどの環境が必要となっていました。そのため、2015年頃から、仮想マシンでのリソース逼迫の改善に向けて、運用監視系サーバーやWebサーバー、プロキシサーバー、各種データベースサーバーなどの環境を順次Dockerに移行。非常に便利になったと同時に、全社的な仮想環境の乱立によるラックスペースの不足や各環境のリソース逼迫も問題視されていたため、Dockerによるアプリケーション提供基盤の検討も始めました。

野原は、Dockerを活用することで、リソースの削減や、ハードウェア環境の集約、システムポータビリティの向上、高速デプロイ・高速スケール、Dependency（依存関係）問題からの解放など、多くのメリットがあるといいます。その一方で、ユーザーのDocker知識の不足や、コンプライアンス・セキュリティのリスク、監視やメンテナンスの運用、ステートフルなデータの制限などの課題も多いと指摘します。

そのため、Docker導入の要件としては、特別な知識が不要で、セルフサービスや社内のセキュリティ要件を満たしつつ、運用効率が向上するものとし、オーケストレーターにはRancher、インフラにはNUTANIX、コンテナOSにはCoreOS、レジストリにはDocker Registryを選定しました。
しかし、利用したいアプリケーションが全てRancherのカタログにあるわけではなく、状況によってはカスタマイズや独自アプリケーションのコンテナをビルドする必要があるほか、ビルドした独自のアプリケーションイメージはライセンス契約によってDocker Hubのパブリックリポジトリに公開できないものも含まれる可能性もあります。そのため、プライベートカタログはDocker-composeとRancher-composeというyamlファイルを入れることでUIを構成。各composeファイルはGitHub Enterpriseに置き、UIからリポジトリのURLを指定して実装可能にしました。グローバルで公開できるDockerイメージはDocker Hubを利用して自動ビルド。一方、公開できないDockerイメージはGitHub EnterpriseとJenkinsでビルドし、Twistlock（コンテナセキュリティ）で脆弱性をスキャンした上で、社内のDocker Registryへpushするようにしています。

Macnica Private Docker Cloudの構成概要

こうして構築されたMacnica Private Docker Cloudにより、物理リソースの削減や、エンジニアによる環境構築の工数削減のほか、アプリケーションを利用開始するまでの時間も短縮したと強調します。また、取扱い製品のデモ環境としての利用や、アプリケーションのバージョン別のUI確認や動作確認、OSSコミュニティとの情報共有によるナレッジ向上も実現しているということです。

今後は、運用環境のスケールや、Kubernetes環境へのマイグレーション、Registryおよび運用環境へのTwistlock適用などもおこなっていく考えだと野原は語りました。

最後に、マクニカの根本 竜也から、マクニカが提供するDevOpsツール群に関して、GitHub Enterprise、CircleCI、そしてJFrogが密接に連携する形でのトータル支援を提案し、第2回GitHub Enterpriseユーザー会の全てのセッションは終了しました。

マクニカでは各ベンダーへの問い合わせ窓口の一本化と、専任チームによる日本語での導入・運用・拡張の各技術支援が可能ですと語る根本

熱気も醒めやらぬ中、終了後の懇親会では多くの方にご参加いただき、セッションを担当した講演者との情報交換が活発におこなわれました