CircleCI実践入門でちょとつまずいたのでメモ
はじめに
9/14にCircleCI実践入門が発売されました。
ここ一年くらい業務で利用していなかったので、再入門する為に読みました！
インフラエンジニアなのでterraformのserverless frameworkなどIaCのCI/CDとしては利用していたのですが、アプリ開発でのCI/CDの利用については理解できていませんでした。
本書の「9.モバイルアプリ開発での活用」は、サンプルコードを利用したアプリ開発における利用方法が記載されており、アプリ開発の知識のない人でも利用イメージを掴む事ができるようになっていたのがとてもよかったです！
書籍内ではモバイルアプリのE2Eテストとして、「Test Lab」を利用しているのですが、利用した事がなく少しつまずいたので、調べついでに残しておきたいと思います。
Firebase Test Labとは
Firebase Test Lab を使用すると、アプリをさまざまなデバイスや構成でテストして、ユーザーのデバイスでどのように動作するかをより正確に把握できます。
無料プラン（Spark）の制限
とりあえず動きが確認できればいいだけなので、無料プランの利用枠を確認。
Spark プランと Flame プランの割り当て Spark と Flame のどちらのプランでも、テスト実行のみに限定された 1 日の割り当て（仮想デバイス 10 台と物理デバイス 5 台）を使用してテストできます（1 日最大 15 台のテスト実行）。この制限はテストの種類（インストゥルメンテーション、Robo、ゲームループ）やマトリックスに関係なく適用されます。
Test Labの準備
書籍内ではTest Labの準備として以下の記載があります。
サービスアカウントへ設定するロール
サービスアカウントの作成作業を進めるとロールの設定画面が表示されます。
書籍内では言及してないのですが、以下のドキュメントをみると編集者ロールが必要な事がわかります。
2.サービス アカウントを作成します。サービス アカウントはスパムチェックやキャプチャ プロンプトの対象になりません。対象にすると、CI ビルドがブロックされる可能性があります。Google Cloud Platform Console で、編集者のロールを持つサービス アカウントを作成します。
サービスアカウントの権限設定にて編集者ロールを追加します。
ちなみに、権限がないと以下のエラーが出ます。
ERROR: (gcloud.firebase.test.android.run) Unable to access the test environment catalog: ResponseError 403: Not authorized for project ***********************
課金の有効化
編集者ロールを追加後に実行すると今度は以下のエラーが出ました。
Creating results bucket [gs://cloud-test-***********************-blueprints] in project [***********************]. ERROR: (gcloud.firebase.test.android.run) Permission denied while creating bucket [cloud-test-***********************-blueprints]. Is billing enabled for project: [***********************]?
書籍内に記載されていますが、Test Labのテスト結果はGoogle Cloud Storageに保存される為、bucketの作成権限がない事によるエラーのようです。
storage.buckets.create権限を含むStorage 管理者ロールをさらに追加します。
が、このロールも設定してもエラーが解消されません。
Creating results bucket [gs://cloud-test-***********************-blueprints] in project [***********************]. ERROR: (gcloud.firebase.test.android.run) Permission denied while creating bucket [cloud-test-***********************-blueprints]. Is billing enabled for project: [***********************]?
サービスアカウントの再作成など色々試してダメで、Cloud Strageのコンソールをみると
Cloud Strageは課金を有効化しないと使えないんですね。。
有効化したら無事にworkflowが実行できました。
おわりに
最終的にはStorage 管理者ロールは不要で、編集者ロールだけで動作します。
GCPを利用した事ない人は同じ事になりそうだったので、誰かの助けになれば幸いです。
CNDT2020での各社の取組から学ぶコンテナセキュリティ
はじめに
CNDT2020において、コンテナセキュリティに関連するセッションが複数ありました。
自分自身が今後、マイクロサービス化を推進する立場になった時の為に、コンテナセキュリティにどう取り組むべきかを、各社の事例を参考にまとめておこうと思います。
まず確認すべきはNIST SP 800-190
多くのセッションにて出てくるコンテナセキュリティを考える上での準拠すべき基準が「NIST SP800-190」でした。
NIST SP800-190にて定義されているコンテナ技術における5つのリスク。
- イメージのリスク
- レジストリのリスク
- オーケストレータのリスク
- コンテナのリスク
- ホストOSのリスク
基本として上記リスクに対して、色々なアプローチをする必要があります。
以降からは各社の取り組みについて簡単にまとめてます。
詳細については動画にて確認できるので、ざっくりどんな実装になっているのかをスライドベースで記載してます。
Yahoo! JAPAN
実行環境をスコープとしたセキュリティの実装にてSysdigセキュアの導入
製品選定に際し目指していた業務フロー
振舞い検知
- セキュリティポリシーを製品を通してk8sに導入し、SOC（後述）にて常に監視
- 既に利用しているsplunk Enterprise SecurityにLog/Alertを飛ばして監視
構成チェック
- CaaS管理者にてポリシーを定義し、k8sの設定に不正な設定がないかチェック
- ポリシー違反があればエンジニアに通知
CIS Benchmarkを利用して自前で実装しようとしていたが断念
脆弱性検知
製品選定
西海岸へ実際に足を運んで５社を周り選定
UIなど想定に一致したSysdigを選定
体制と役割
システム構成
- Watch Tower / Sysdig提供のモニタリングSaaS
- Vulnerability Database / 脆弱性データベース
ZOZOテクノロジー
新ID基盤におけるアプリケーション管理のセキュリティ要件である、セキュリティアップデート速やかにより入れるための取り組み。
コンテナイメージ脆弱性検知
- trivyを導入
- GitHubActionsを利用して、定期実行と都度実行
freee
マイクロサービス基盤における外部から受ける攻撃（サイバー攻撃）について、多層防御の考え方でセキュリティを実装。
アメリカの軍事技術だったKill Chainの考え方をサイバーアタックに適用したCyber Kill Chainを元に対応。 対応方針として、輸送以降の段階でログを取ってアラートをあげる。（偵察、武器調達については単独企業での実装は難しい為除外）
外部から受ける攻撃の対策
イメージの脆弱性排除
CI/CDにてイメージの脆弱性を排除
podの挙動監視
動作環境へのセキュリティの対応
EKSはAuditlogはCloudWatchに出力するので、audit-bridgeを利用してFalcoへ通知
node内の検知
EKSのnode全体のセキュリティリスクの検知
Cluster内のネットワーク監視
Cluster内ネットワークのコンテナレベルの監視
シングルテナントで構成してる場合はセキュリティグループで対応可能
マルチテナントの場合に、クラスタ内のPodの通信をセキュリティグループで制御できず、Lateral Movementに気づけない問題がある為対応が必要
感想
１から構築する可能性がある身としては、全て参考になるセッションだった！
trivy、sysdigなど、どのセッションにも出てくるような、デファクトスタンダードとなっている製品もありそうなので、まずはそこから導入してみるのが一番早いのかなという印象でした。
あとは、検知したところで対応できないと意味が無いので、導入と同時に組織に合った体制と仕組み作りができるかが一番の課題になりそうです。
lambdaで「No module named 'numpy.core._multiarray_umath'」の対応したメモ
事象
ローカル環境で動作確認したPythonをLambdaで動かしたら以下のエラーが発生
START RequestId: 8fadcafe-2b18-419b-a131-ac8bebee82a3 Version: $LATEST
[ERROR] Runtime.ImportModuleError: Unable to import module 'lambda/main':
IMPORTANT: PLEASE READ THIS FOR ADVICE ON HOW TO SOLVE THIS ISSUE!
Importing the numpy C-extensions failed. This error can happen for
many reasons, often due to issues with your setup or how NumPy was
installed.
We have compiled some common reasons and troubleshooting tips at:
https://numpy.org/devdocs/user/troubleshooting-importerror.html
Please note and check the following:
* The Python version is: Python3.7 from "/var/lang/bin/python3.7"
* The NumPy version is: "1.19.1"
and make sure that they are the versions you expect.
Please carefully study the documentation linked above for further help.
Original error was: No module named 'numpy.core._multiarray_umath'
END RequestId: 8fadcafe-2b18-419b-a131-ac8bebee82a3
REPORT RequestId: 8fadcafe-2b18-419b-a131-ac8bebee82a3 Duration: 1.63 ms Billed Duration: 100 ms Memory Size: 256 MB Max Memory Used: 62 MB
前提条件
調査
実行環境のPythonバージョンを確認
ローカル
.venv ❯ python --version Python 3.7.4 .venv ❯ pip list Package Version --------------- --------- boto3 1.14.37 botocore 1.17.37 certifi 2020.6.20 chardet 3.0.4 cycler 0.10.0 docutils 0.15.2 idna 2.10 jmespath 0.10.0 kiwisolver 1.2.0 matplotlib 3.2.2 numpy 1.19.1 Pillow 7.2.0 pip 20.1.1 pyparsing 2.4.7 python-dateutil 2.8.1 python-dotenv 0.14.0 requests 2.24.0 s3transfer 0.3.3 setuptools 46.4.0 six 1.15.0 urllib3 1.25.10 wheel 0.34.2
Lambda
Lambdaのバージョンを確認
#!/usr/bin/env python # -*- coding: utf-8 -*- import sys def main(event, context): print(sys.version)
3.7.8 (default, Jul 30 2020, 14:26:00) [GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]
対応
ローカルとバージョンが合ってなかったので、合わせて再度検証
ローカルのPythonバージョンを変更
pyenvでローカル環境を管理してるけど、3.7.8がない
❯ pyenv install 3.7.8 python-build: definition not found: 3.7.8 See all available versions with `pyenv install --list'. If the version you need is missing, try upgrading pyenv: brew update && brew upgrade pyenv
そもそもpyenvが最新じゃないからupgrade
❯ pyenv -v pyenv 1.2.13 ❯ brew upgrade pyenv ❯ pyenv -v pyenv 1.2.20
3.7.8をインストール
❯ pyenv install 3.7.8
ローカル環境を再度作成
❯ pipenv --rm ❯ grep python_version Pipfile python_version = "3.7.8" ❯ pipenv install ❯ pipenv shell .venv ❯ python --version Python 3.7.8
ローカル環境で動作確認後、Lambdaデプロイして動かしたけど事象変わらず。。
serverless frameworkでアップロードしてるzipには対象のモジュール含まれてる
.venv ❯ tar tvf .serverless/aws-cost-report.zip | grep _multiarray_umath -rwxr-xr-x 0 0 0 4641720 1 1 2098 numpy/core/_multiarray_umath.cpython-37m-darwin.so
パッケージを取得してる環境の影響の問題
MacOS上ではなく、AWS Linux OS上でパッケージを取得する必要がある
ちなみに上記を見て初めてAWS提供するLayerがあることを知った
色々見てたらクラメソさんの記事を発見！！
まさにserverless framework使ってリリースしてたので、これを参考にしたら行けそう！
serverless-python-requirements設定を変更
dockerizePipの設定を追加
pythonRequirements: dockerizePip: true
再度デプロイしたらlambdaでも動いた！！
ちなみに一度作ってるとキャッシュを使ってしまうので、deplyログの以下で表示されるキャッシュのディレクトリを削除して再実行する
Serverless: Using static cache of requirements found at .....
slimオプションを試す
slimを有効にして、サイズがどのくらい変わるか確認してみる
pythonRequirements: dockerizePip: true slim: true
前
Serverless: Uploading service aws-cost-report.zip file to S3 (40.43 MB)...
後
Serverless: Uploading service aws-cost-report.zip file to S3 (33.93 MB)...
まとめ
Pure Pythonなライブラリかどうか意識しなくていいように常にdockerizePipを有効にしておこう！
GitHubAPIをRESTからGraphQLに変えたら処理速度が4分16秒から7秒に改善した
はじめに
GitHubの運用にてアカウント一覧を作成する必要があり、GitHubAPI v3（REST API）を使って実装したのですが、アカウント数の増加とともに処理時間が増えてしまう為、GitHubAPI v4（GraphQL）に変更したメモです。
改善結果
アカウント数が399の状態で実行した結果が以下です。
REST API / 256s (4分16秒)
INFO : 2020-07-28 11:02:11,810 : Rest Api Start INFO : 2020-07-28 11:06:27,565 : member count: 399 INFO : 2020-07-28 11:06:27,565 : Rest Api End
GraphQL / 7s
INFO : 2020-07-28 11:06:27,565 : GraphQL Start INFO : 2020-07-28 11:06:34,046 : member count: 399 INFO : 2020-07-28 11:06:34,046 : GraphQL End
取得するデータ
GitHubアカウントから以下の情報を取得します。
- login
- name
- createdAt
- role
コード
RESR API
PyGitHubを使うことで簡単に取得できます。
GraphQL
GraphQLは一回で取得できる件数に制限があり、制限を超えている場合は動的に次のページ情報を指定する必要があったのですが、以下に参考例があったので簡単に実装できました！（感謝！！）
An example on using the Github GraphQL API with Python 3 · GitHub
自分はOrganizationも変数化したかったので、その部分を一部修正してます。
まとめ
GraphQLに変える事でここまで大幅に処理時間が改善できると思っていなかったので感動ものでした！！
動作環境を考えると、処理時間次第でlambdaで実装するか、コンテナ化するかなど、費用面や開発コストにも大きく影響するので、GraphQLの理解を深めて今後の実装に生かしていきたいと思います！！
API Gatewayチュートリアルをserverless frameworkを使って構築してみた
はじめに
API Gateway + LambdaのREST API環境をserverless frameworkで作成しました。
作成した環境は以下のAPI Gatewayチュートリアルの環境です。
Code
今回環境構築に使用したコードは以下になります。
GitHub - dehio3-org/api-gateway-create-api-as-simple-proxy-for-lambda at v1.0
serverless.yml
serverless.ymlに定義したチュートリアルの各設定項目は以下になります。
service: name: HelloWorld # 今回作成するサービス名を定義 provider: name: aws region: us-east-1 # 「Hello World」Lambda 関数を作成する-2 runtime: nodejs12.x # 「Hello World」Lambda 関数を作成する-6.b stage: test # API をデプロイしてテストする-3 apiName: LambdaSimpleProxy # 「Hello, World!」 API を作成する-3.b endpointType: REGIONAL # 「Hello, World!」 API を作成する-3.b functions: GetStartedLambdaProxyIntegration: handler: index.handler # 「Hello World」Lambda 関数を作成する-7(デフォルト値) name: GetStartedLambdaProxyIntegration # 「Hello World」Lambda 関数を作成する-6.a events: - http: path: /helloworld # 「Hello, World!」 API を作成する-4.d,4.e method: any # 「Hello, World!」 API を作成する-5.c integration: lambda-proxy #「Hello, World!」 API を作成する-5.d,5.e package: exclude: - '**' include: - 'index.js' # 「Hello World」Lambda 関数を作成する-7 (ローカルに関数コードファイルを作成)
今回はチュートリアルに従い最小限の設定でしたが、メモリサイズやタイムアウトなど他の設定値についても指定可能です。
Deploy
serverless frameworkをインストールします。
❯ yarn install
作成したserverless.ymlに従いリソースを作成します。
❯ yarn deploy yarn run v1.22.4 $ serverless deploy Serverless: Packaging service... Serverless: Excluding development dependencies... Serverless: Creating Stack... Serverless: Checking Stack create progress... ........ Serverless: Stack create finished... Serverless: Uploading CloudFormation file to S3... Serverless: Uploading artifacts... Serverless: Uploading service HelloWorld.zip file to S3 (823 B)... Serverless: Validating template... Serverless: Updating Stack... Serverless: Checking Stack update progress... .............................. Serverless: Stack update finished... Service Information service: HelloWorld stage: test region: us-east-1 stack: HelloWorld-test resources: 11 api keys: None endpoints: ANY - https://3rxvyvg3t3.execute-api.us-east-1.amazonaws.com/test/helloworld functions: GetStartedLambdaProxyIntegration: GetStartedLambdaProxyIntegration layers: None ✨ Done in 127.69s.
Test
デプロイ結果よりエンドポイントのURLが確認できるので、チュートリアルに従いリクエストを送信します。
endpoints:
ANY - https://3rxvyvg3t3.execute-api.us-east-1.amazonaws.com/test/helloworld
curl -s -X POST "https://3rxvyvg3t3.execute-api.us-east-1.amazonaws.com/test/helloworld?name=John&city=Seattle" -H "content-type: application/json" -H "day: Thursday" -d "{ \"time\": \"evening\" }" | jq
正しくレスポンスが返ってきました！
{ "message": "Good evening, John of Seattle. Happy Thursday!", "input": { "resource": "/helloworld", "path": "/helloworld", "httpMethod": "POST", ~中略~ }, "queryStringParameters": { "city": "Seattle", "name": "John" }, "multiValueQueryStringParameters": { "city": [ "Seattle" ], "name": [ "John" ] }, ~中略~ "body": "{ \"time\": \"evening\" }", "isBase64Encoded": false } }
serverless framework の用に作成されるリソース
serverless frameworkを利用してリソースの作成を行う場合、serverless.ymlに定義していないいくつかのリソースが作成されます。
IAM Role
チュートリアルの「「Hello World」Lambda 関数を作成する-6.d」にて作成していたLambda用のロールが自動で作成されます。
serverless.yml内で個別のポリシーを指定していない場合は、以下のログ出力の為のポリシーがデフォルトで適用されます。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:CreateLogGroup" ], "Resource": [ "arn:aws:logs:us-east-1:<acount id>:log-group:/aws/lambda/GetStartedLambdaProxyIntegration:*" ], "Effect": "Allow" }, { "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:us-east-1:<acount id>:log-group:/aws/lambda/GetStartedLambdaProxyIntegration:*:*" ], "Effect": "Allow" } ] }
S3
lambdaのコードとCloudFormationのテンプレートを保存するバケットが自動で作成されます。
デプロイ毎に日時のパスが作成されファイルが管理されます。
packageコマンドを使う事で、アップロードされるパッケージを事前に確認する事もできます。
❯ yarn run package yarn run v1.22.4 $ serverless package Serverless: Packaging service... Serverless: Excluding development dependencies... ✨ Done in 9.98s. ❯ ls -ltr .serverless total 72 -rw-r--r-- 1 tomohide staff 1653 7 8 00:27 cloudformation-template-create-stack.json -rw-r--r-- 1 tomohide staff 823 7 8 00:27 HelloWorld.zip -rw-r--r-- 1 tomohide staff 8721 7 8 00:27 cloudformation-template-update-stack.json -rw-r--r-- 1 tomohide staff 14279 7 8 00:27 serverless-state.json ❯ tar tvf .serverless/HelloWorld.zip -rw-r--r-- 0 0 0 1745 1 1 1980 index.js
serverless.yml内のpackageにて、アップロードするパッケージを意図的に指定しなかった場合は、カレントに存在する全てのファイルを関数コードファイルとしてアップロードします。
関数コードファイルのサイズが大きくなりすぎて、Lambdaコンソール画面にて関数コードファイルが展開されず中身が確認できない場合などに便利です。
Cloud Formation
serverless frameworkはCloudFormationにてserverless.ymlに定義したAWSリソースを作成している為、スタックが作成されます。
まとめ
雰囲気で使ってたserverless frameworkを把握する為、チュートリアルベースで設定方法を再確認してみました。
S3やCloud Formationなどは、serverless.ymlからは確認できないので、仕組みを知らずに触っていると把握しにくい内容かもしれません。
また、各リソース名はservice.name+stageとなるので、それぞれの値を設定する時は意識して設定する必要がありそうです。
今回はチュートリアル内容をそのまま構築しましたが、次回以降でカスタムドメインの設定や、GitHubActionsでの自動デプロイなども試してみたいと思います。
AWS Amplify オンラインハンズオンのコストについて
はじめに
GWにAWSのAmplifyオンラインハンズオンをやってみました。
Amplifyは全くの未経験でしたが、ハンズオンの資料も分かりやすく、動画も提供されているので、詰まることなくスムーズに体験することができました。
ただハンズオンの中でAmplifyやElasticSearch等複数のリソースを作成する為、個人の環境で行うには費用が気になる方もいるかと思います。
参考までに自分がハンズオン実施した際のコストを共有したいと思います。
実施内容
期間
5/6の朝10時ごろから開始して、終わってリソースを削除したのは22時頃です。
なので、１日かけてハンズオンを実施した場合のコストと思ってください！
子供の相手や家事をしながらだったので12時間かかってますが、ハンズオン自体は4、5時間程度で終わるボリュームです。
作成した環境
ハンズオンの中ではバックエンドとして３つの環境を作成します。
最初はproduction環境のみでアプリケーションの作成を行い、後半の章の「7.複数メンバーでの開発」からはstaging designの二つの環境を追加していきます。
今回はハンズオンに忠実に作業したので、３つとも環境を作成しました。
ただ、staging designを作成するのは後半だったので、実際にリソースとして稼働していたのは、４時間程度だったとおもいます。
かかったコスト
Cost Explorerの日毎のコストに確認したコストが以下です。
5/5のコスト:$0.08
5/6のコスト:$1.55
という事で、ハンズオンを実施した日のコストとしては、普段より$1.47(156円)増えてました。
ちなみリソースを作成したリージョンはバージニアです。
まとめ
ハンズオンは手順も細かく記載されていて、アプリについてはコードのコピペで作成できる為、フロントエンドの開発経験がない人でも簡単にAmplifyを理解することができました！
パッケージのインストール時も動画を止めずに撮影しているので、動画を流しっぱなしでも同じ速度で作業を進められるのが地味によかったと感じました！
１日で終わらせれば$1.47(156円)程度しかAWSのコストも掛からないので、興味ある方は是非トライしてみてください！
「JavaScript(ES6)/Vue.js/TypeScript フロントエンド技術入門」のメモアプリをGitHub ActionsでGitHub Pagesにデプロイしてみた。
はじめに
Stay HomeのGWということで、今年こそは何かしらの勉強をするぞ！！
という意気込みの元、たにぐち まことさんがUdemyにて公開している「フロントエンド技術入門」にチャレンジしてみました！
本来なら、全てのレクチャー（07:58:23）を最初から受けたいところですが、小さい子供がいる家庭ではそんな時間は取れるわけもなく。。
とにかく手を動かして、何かしらのSPAを作ってみようという事で、最後のコースである「Vue CLIで、SPAを開発しよう」のメモアプリを作成しました。
で、せっかくアプリ作るならデプロイを自動化するまでが開発！という事で、最後のレクチャーである「アプリケーションをビルドしよう」の続きで、GitHub Actionsを使ってGitHub Pagesで公開する方法の記事です。
作業
GitHubにnotepadプロジェクトを上げる
レクチャー通りに作業を進めていれば、「notepad」というディレクトリ配下でプロジェクトの開発を行っていると思います。
なので、GitHubでリポジトリを作成し、「notepad」配下の資産をpushします。
(注意：GitHub Pagesを使う場合はリポジトリをPublicで作成する必要があります。)
$ cd notepad $ git remote add origin https://github.com/dehio3/vuejs-handson-notepad.git $ git push -u origin master
vue.config.jsを追加する
GitHub Pagesで公開する場合、URLは以下になります。
その為、そのままの設定では公開後のCSSなどが404で見つからずサイトが正しく表示されません。
対策として、vue.config.jsのpublicPathにrepository名を設定する事で、サブパスでのアクセスを可能にします。
vue.config.js
module.exports = {
publicPath: '/' + process.env.GITHUB_REPOSITORY.split('/')[1]
}
GitHub Actionsではデフォルトの環境変数がいくつか存在し、その中のGITHUB_REPOSITORYにて、所有者名を含むリポジトリ名（例：octocat/Hello-World）を取得できます。
その為、publicPathに設定したいリポジトリ名を環境変数から動的に取得して設定しています。
（リポジトリ名だけを含む環境変数は見受けられませんでした。）
GitHub Actionsを作成する
デプロイを自動化する以下のworkflowを追加します。
.github/workflows/vue-deploy.yml
name: vue-deploy on: push: branches: [ master ] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Use Node.js uses: actions/setup-node@v1 with: node-version: "12.x" - name: Cache dependencies uses: actions/cache@v1 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }} restore-keys: | ${{ runner.os }}-node- ${{ runner.os }}-build-${{ env.cache-name }}- ${{ runner.os }}-build- ${{ runner.os }}- - name: install run: npm install - name: build run: npm run build - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./dist # default: public
今回GitHub Pagesへのデプロイについては、actions-gh-pagesというActionsを利用しています。
buildを実行するとデフォルトでdist配下にソースが格納されるので、publish_dirには./distを設定しています。
GitHub Pagesを設定する
上記のGitHub Actionsのworkflowをpushすると、GitHub Actionsが実行され、gh-pagesというブランチが作成されます。
ブランチを切り替えてみるとわかりますが、これはactions-gh-pagesActionsにて作成された、./dist配下のソースだけが格納されたブランチです。
GitHub PagesではこのブランチをSourceとして設定します。
あとは、表示されているGitHub PagesのURLにアクセスすると、作成したメモアプリが表示されます。
まとめ
GitHub Pagesのパスによる問題は、他にも対処法があるようでしたが、なるだけレクチャーの内容には手を加えないようにする為、新規にvue.config.jsを追加する方法にしました。
また、汎用的に使えるようにpathについては、環境変数から値を設定できるようにしました。
Vue.jsについては、基本をすっ飛ばしてるので雰囲気だけ掴んだ感じなので、GW明けてからも空いた時間で少しずつレクチャーを進めて行きたいと思います！
