GitHub Actions で失敗するようになった話
「何も変えていない」という訳ではないですがCI/CDに関係する部分は変えていないのに失敗するようになったというお話です。 2021/12/10から急に動かなくなりました。
結論から言うと nodejs のバージョンを指定せずに組んでいた為、デフォルトバージョンが16に変わったせいでした。
ここにも書いてありますが「常にNode.jsのバージョンを指定し、システムのバージョンに依存しないことをお勧めします」の通りですね。
今後とも更新ログには注意を払っていきたい所存です。
さくらのメールボックスを独自ドメインで使う
概要
さくらのメールボックスを独自ドメインで使う際、毎度混乱するので備忘録として
今回は sub.example.com を追加する想定
さくらのメールボックス側で設定すること
この「ドメインの追加」は「このドメイン名でメールが来るよ」という程度のもので、DNSの移譲まではしなくても良いみたいです。（ネームサーバーを変えて下さい、と記載はありますが・・・）
- ドメインの追加
- メールアカウントの追加
- 「メール」→「メール一覧」メニューから「新規追加」ボタンをクリック
- 「ユーザ名」「パスワード」など必要事項を記入して「作成する」ボタンをクリック
- mytest@sub.example.com であればユーザ名は mytest
- ホスト名の取得
- 「サーバ情報」→「サーバ情報」メニューを選択
- ホスト名に記載の xxx.sakura.ne.jp をメモしておく（後で使う）
注意したいのは複数のドメインを関連付けられるがアカウント名は他と被ってはいけない点です。
本来、ドメインが異なればアカウント名が同じでも問題ありませんが、さくらのメールボックスは関連付けるドメイン全てで被らないように命名する必要があります。
独自ドメイン側で設定すること
- sub.example.com レコードの MX に「10 xxx.sakura.ne.jp」を設定する
- 「xxx.sakura.ne.jp」の部分は前述のホスト名と合わせること
- 優先順位など必要に応じて変更すること
お使いのDNSサービスによって管理画面が異なるので設定方法は各サービスマニュアルをご参照ください。
メモ
反映されるまでに最大48時間とあるので、余裕を持って設定できると良いですね。実際には10分くらいで反映される事が多いと思いますが。
github actionsでログをファイル出力し、失敗時に表示する例
概要
github actionsでstep毎に処理を分けているのですが、テスト処理でバックエンドが失敗した時にログが確認できなくて困っていました。
stepはプロセスに分かれているという事でバックエンドを開始した直後の処理は標準出力が拾えるのですが、別のstepに行くと標準出力は残りません。
そこでバックエンドの出力をローカルのファイルに書き出しておき、失敗した時だけ後続のstepで標準出力に出すという事で解決できました。
その時の内容になります。
やり方
jobs:
mytest:
runs-on: ubuntu-latest
steps:
- name: start backend
run: |
npx serverless offline start --stage dev > backend.log &
npx wait-on -t 60000 https-get://api.example.com:9000/manage/v1/echo
- name: output-log-on-fail
if: failure()
run: |
cat ./backend.log
1個目のstepでバックエンドプロセスを実行しています、この時の出力をbackend.logファイルにしています。
そして2個目のstepで失敗時のみbackend.logを標準出力に出しています。
これで失敗時だけログを見られるようになりました。
sapislab開発記録 - はじめに
概要
本投稿はWebサービスsapislab（サピスラボ）開発の記録になります。
sapis は Simple API Service、lab は laboratory の略で研究所・実験室の意です。
簡単なWebAPIサービスの提供および管理画面の構築を行います。
具体的にやりたいこと
本当はやってみたいが仕事ではなかなか機会が無い部分を少しずつやっていこうと思っています。
具体的にやりたいことは
- OpenAPI を使った設計、半自動ソース生成
- RESTful API
- CI/CD環境
- 自動テスト
- サーバーレス（S3＋lambda＋dynamodb）
- クリーンアーキテクチャ、ドメイン駆動設計
- SPA（vue）
です。
最終的にサーバーレスでは維持できなくなる事が予想されるので、クリーンアーキテクチャのフレームワーク層とリポジトリ層を置き換えて一般的なWebサーバー＆RDBに切り替えられるようにします。
クライアント側はSPAにするので、APIの設計がキモになりますね。
RESTfulになるようにリソース定義を意識していきます。
当面の目標
当面の目標は下記の提供とします。
当ブログで扱っているRaspberry Piでテレビ電話する方式の状態制御部分が提供できたらゴールです。
（その後は予約サービスとか簡単なドメインを作ってみたい）
プライベート時間で作っていくので完成しないかもしれませんので、ご了承くださいｗ
Webシステム開発でAPIベースにするメリット・デメリット考察
概要
Webシステム開発でAPIを提供し、クライアント側で描画するパターン（SPA）についてメリット・デメリットを思いつきレベルで挙げてみる
主にクライアント側のお話で、ここではフレームワークとしてvueを、言語としてtypescriptを使う想定
メリット
- アプリ開発も並行する場合は都合が良い（どちらでも使えるので）
- クライアント側で非同期処理がやりやすい
- ページ遷移が少なく、利用者のストレスが減る（と思われる）
- スケールし易い
- これはサーバー側インフラの拡張のし易さのように見えるが、従来のサーバー側で画面を構成して返すパターンでも同じはず
- マイクロサービス化して連携させる事によるスケールのことを指しているような気がする
デメリット
- 習得すべきフレームワークや言語が増えるため未経験の場合は初期コストがかかる
- 知見（ノウハウ）が得られた頃には開発中盤で、実は活かせてない事に気づいたりする
- コンポーネント化を前提としたHTML制作は開発エンジニアでないと難しい事が多く、HTML制作メンバーが使えない
- 開発エンジニアがHTML・CSSがそんなに得意で無い場合、余計に時間がかかる
- API設計に問題があるとサーバーの負荷が増大する
ポイント
AWSのCDKでちょこちょこ使う細かいパターンのメモ
概要
AWSのCDKでちょこちょこ使う細かいパターンのメモ
IAMロールをインラインで用意するケース
ecr-accessという名前で、アクション'ecr:'、リソース''、許可の組み合わせで作成する例
import iam = require('@aws-cdk/aws-iam');
const myRole = new iam.Role(this, "MyRole", {
assumedBy: new iam.ServicePrincipal('codebuild.amazonaws.com'),
inlinePolicies: {
'ecr-access': new iam.PolicyDocument({
statements: [
new iam.PolicyStatement({
effect: iam.Effect.ALLOW,
actions: [
'ecr:*'
],
resources: [
'*'
]
}),
],
}),
}
});
バケットへのアクセス用ロール（自アカウント利用版）
import cdk = require('@aws-cdk/core');
import s3 = require('@aws-cdk/aws-s3');
import iam = require('@aws-cdk/aws-iam');
const bucket = new s3.Bucket(this, 'MyBucket', {
bucketName: 'bucket name here',
});
const myRole = new iam.Role(this, "MyRole", {
assumedBy: new iam.AccountPrincipal(cdk.Stack.of(this).account),
inlinePolicies: {
's3-access': new iam.PolicyDocument({
statements: [
new iam.PolicyStatement({
effect: iam.Effect.ALLOW,
actions: [ 's3:GetObject*', 's3:GetBucket*', 's3:List*', 's3:DeleteObject*', 's3:PutObject*', 's3:Abort*' ],
resources: [ bucket.bucketArn, bucket.bucketArn+'/*' ],
}),
],
}),
}
});
