8.2K Views
June 19, 23
スライド概要
potatotips #82
iOSアプリ開発でGitHub Actionsの self-hosted runnerを使う YORIFUJI MITSUNORI potatotips #82
自己紹介 • 名前 • YORIFUJI MITSUNORI • Twitter/GitHub/Zenn @yorifuji • 経歴 • SIerでシステムエンジニア -> 昨年4月からFOLIOでiOSエンジニア(2年目) • Swift, Flutterアプリ開発 • 最近興味のあること • CI/CD
About GitHub Actions • GitHubに統合されたCI機能 • 特別な設定は必要なくGitHubを利用していれば直ぐに利用が始められる • 他社製のCI/CDサービスのサインアップやGitHub連携などの作業が不要 • GitHub上で発生するイベントをトリガーにワークフロー(ジョブ)を実行できる • ファイルの変更(コードのプッシュ)、ブランチ/PR/Tagに関するイベント • Issueの作成、PRのApprove、誰かがリポジトリをforkした、等 • 用途 • test、build(ipa)、deploy(App Store Connectへのアップロード)など
name: sample workflow run-name: Hello GitHub Actions Work ow on: [push] ジョブの内容を記述したYAMLファイル をリポジトリの .github/work ows fl fl フォルダに追加する jobs: job1: runs-on: macos-latest steps: - run: uname -a - run: echo Hello, job1 job2: runs-on: ubuntu-latest steps: - run: uname -a - run: echo Hello, job2
GitHub-hosted runner • GitHubが提供するワークフローの実行環境(VM) • Windows, Linux, macOS • ワークフローでLabelを使って指定する runs-on: macos-latest • その都度クリーンな環境が割り当てられる • XcodeやAndroid SDKなどの代表的な開発ツールがインストール済み
GitHub-hosted runnerの構成 • https://github.com/actions/runner-images で公開されている
https://github.com/actions/runner-images/blob/main/images/macos/macos-13-Readme.md (2023.6.18時点)
Example fl .github/work ows/sample.yml
Example fl .github/work ows/sample.yml
料金 • パブリックリポジトリでの利用は無料! • プライベートリポジトリ • GitHub-hosted runnerの利用時間とストレージに対して課金 • 無料枠あり
GitHub Actions(GitHub-hosted runner)の痒いところ • macOSインスタンスのスペック • 3-Core Intel mac • Xcodeの更新にタイムラグがある • Xcode14.3.1が最新、Xcode15.0(beta)はまだ使えない(6.18時点) • PRがApproveされているのでもう直ぐ使えそう(?) • https://github.com/actions/runner-images/pull/7707 • (秘匿情報の)ファイル管理 • GitHub Actionsにファイルアップローダーは提供されていない • 配布用証明書、Provisioning Pro leなどの扱いに一手間かかる fi • プライベートリポジトリでの課金
About self-hosted runner • self-hosted runner=所有しているマシンでワークフロー実行するシステム・ホスト • イベントをハンドリングしてローカルマシンでワークフローを実行するためのrunner(agent)が提供されている • 特徴 • 任意のマシンをワークフローの実行に利用できる • 開発ツールも必要に応じて自由にインストールできる • プライベートリポジトリでのワークフローの実行時間に対する料金が発生しない • 制約 • マシンの管理・運用コスト(OSのアップデートやソフトウェアなど)は自分もち • VMの機能は提供されていないのでゴミが残ったりする • GitHub-hosted runnerとself-hosted runnerの仕様差異への対応 -
Setup self-hostd runner name: self hosted sample workflow run-name: Hello self-hosted runner • CIサーバー用のマシンを用意する • iOS開発ならmacOS端末が必要 • 開発ツールをインストール • Xcodeなど • self-hosted runnerをインストール • ワークフローでself-hosted runnerを指定 on: [push] jobs: job1: runs-on: self-hosted steps: - run: uname -a - run: echo Hello, job1
CIサーバのマシンを用意する...🤔
💸
potatotips
GitHub-hostedとself-hostedのワークフロー共通化 • GitHub-hostedとself-hostedのワークフローを共通化すると異なるリポジトリ間 で再利用しやすい • Variablesを使うとワークフローから参照できる変数をリポジトリに対して設定 できる
Xcodeバージョンの切り替え • GitHub-hostedは複数のXcodeがインストール済み • バージョンの切り替えはワークフローで env: を定義してDEVELOPER_DIR環境変数を設定する • export DEVELOPER_DIR=/Applications/Xcode... と同じ効果を発揮 • self-hostedでも同じパス構成でインストールすると共通化できる
iOSビルドの証明書管理 • ipaのビルドは配布用証明書(Apple Distribution)とProvisioning Pro leが必要 • 証明書管理パターン • ホストマシンに直接インストール(Keychainに登録) • self-hosted runnerでの利用&特定のTeamの署名のみであれば選択可能な方法 • GitHub Actionsが提供するSecrets(Key-Value store)を使ってリポジトリに登録 • ファイルをbase64でencodeして登録 -> 実行時にdecodeしてファイルに書き出す fi • Cloud signing(App Store Connect API)
Cloud signing(App Store Connect API) • Xcode13 以降で利用可能な、Appleのサーバー上でipaに署名する機能 • https://developer.apple.com/videos/play/wwdc2021/10204/ • XcodeではAppleIDを利用、CI環境(xcodebuild)ではApp Store Connect APIの認証情報が必要 • メリット • 配信証明書(Apple Distribution)やProvisioning Pro leの作成・配置が不要 • App Store Connect APIの認証情報は無期限のため更新の必要がない • デメリット fi • App Store Connect APIの認証情報をAdmin権限で払い出す必要がある
Cloud signingの利用手順 • プロジェクトファイルのAutomatically manage signingが有効であること
Cloud signingの利用手順 • App Store ConnectでAPIキーを払い出す • Issue ID • Key ID • .p8ファイル
ExportOptions.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
...
<key>method</key>
<string>app-store</string>
<key>signingStyle</key>
<string>automatic</string>
<key>destination</key>
<string>export</string>
<key>teamID</key>
<string>{ご利用のTeamID}</string>
...
</dict>
</plist>
XcodeからArchiveを実行した後にOrganizerのDistribute AppでExportして生成
xcodebuild with Cloud signing xcodebuild archive CODE_SIGNING_ALLOWED=NO ... xcodebuild -exportArchive ... \ -exportOptionsPlist ./ExportOptions.plist \ -allowProvisioningUpdates \ -authenticationKeyIssuerID $ISSUER_ID \ -authenticationKeyID $KEY_ID \ -authenticationKeyPath `pwd`/private_keys/AuthKey_$KEY_ID.p8 • xcodebuild archiveにCODE_SIGNING_ALLOWED=NOを付与することでarchiveでの署名を無効化する • xcodebuild -exportArchiveにCloud signingに必要なパラメータを指定する
fl fl xcodebuild with Cloud signing(for Flutter iOS) flutter build ios --no-codesign xcodebuild archive CODE_SIGNING_ALLOWED=NO ... xcodebuild -exportArchive ... \ -exportOptionsPlist ./ExportOptions.plist \ -allowProvisioningUpdates \ -authenticationKeyIssuerID $APPLE_API_ISSUER_ID \ -authenticationKeyID $APPLE_API_KEY_ID \ -authenticationKeyPath `pwd`/private_keys/AuthKey_$APPLE_API_KEY_ID.p8 • utter build ios --no-codesign 以外は共通 • utter build ipa には対応していない模様
self-hosted runnerでのCacheの利用 • ワークフロー高速化(CIを早く終わらせる)のために中間生成物や パッケージマネージャの依存関係はCacheの利用が推奨されている • CocoaPods, Pub.devなどのローカルキャッシュして処理をスキップ • 標準のキャッシュ機能(Cache action)を使うとGitHubが提供する キャッシュサーバを各リポジトリ最大10GBまで利用できる
self-hosted runnerでCacheが遅い • GitHub-hosted runner • Cacheのupload/downloadが速い(over 1Gbps) • 1GB程度のキャッシュであれば10秒ほどで展開できる • self-hosted runner • めちゃくちゃ遅い(20Mbps程度) • Cacheのsave/restoreに時間がかかって使わない時よりも遅くなる😰
self-hosted runnerでキャッシュが遅いのはなぜか • GitHub Actionsのインフラの実態はAzure Pipelines(と言われている) • GitHub-hosted runnerのロケーション • 「macOS イメージを実行するエージェントは、3 コアの CPU、14 GB の RAM、14 GB の SSD ディスク領域を備 えた Mac Pro にプロビジョニングされます。 これらのエージェントは、Azure DevOps 組織の場所に関係なく、 常に米国で実行されます。」(Azure Pipelineより) • GitHub-hosted runnerでのキャッシュが爆速なのは利用しているキャッシュサーバ(Azure Blob Storage)が物理的 に近いロケーションにあるからではないか • self-hosted runnerで遅い理由は(私の場合)自宅のself-hosted runnerとGitHubのキャッシュサーバ(アメリカ)間 の通信が遅いため(たぶん) • self-hosted runnerでキャッシュを使うと遅くなってしまうケースがあるので注意
セキュリティ • セキュリティ大事 • https://docs.github.com/ja/actions/security-guides/security-hardening-forgithub-actions • self-hosted runnerはパブリックリポジトリでは使わない • https://docs.github.com/ja/actions/hosting-your-own-runners/managing-selfhosted-runners/about-self-hosted-runners#self-hosted-runner-security • 技術記事なども参考になります • https://engineering.mercari.com/blog/entry/20230609-github-actions-guideline/
GitHub-hosted runner vs self-hosted runner • ほとんどのユースケースではGitHub-hosted runnerが適している • 必要な時にすぐに使えて入門から実運用までカバー • ホスト環境の運用・管理コストがかからない • パブリックリポジトリは無料 • Self-hosted runnerの使い所 • GitHub hostedでは提供されない環境を使いたい
ありがとうございました