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開発記録 - 1.はじめに

概要

本投稿はWebサービスsapislab(サピスラボ)開発の記録になります。
sapis は Simple API Service、lab は laboratory の略で研究所・実験室の意です。
簡単なWebAPIサービスの提供および管理画面の構築を行います。

具体的にやりたいこと

本当はやってみたいが仕事ではなかなか機会が無い部分を少しずつやっていこうと思っています。
具体的にやりたいことは

  • OpenAPI を使った設計、半自動ソース生成
  • RESTful API
  • CI/CD環境
  • 自動テスト
  • サーバーレス(S3+lambda+dynamodb)
  • クリーンアーキテクチャドメイン駆動設計
  • SPA(vue)

です。

最終的にサーバーレスでは維持できなくなる事が予想されるので、クリーンアーキテクチャフレームワーク層とリポジトリ層を置き換えて一般的なWebサーバー&RDBに切り替えられるようにします。
クライアント側はSPAにするので、APIの設計がキモになりますね。
RESTfulになるようにリソース定義を意識していきます。

当面の目標

当面の目標は下記の提供とします。

  • 管理画面
    • ユーザー管理
    • APIキー管理
    • キーバリュー管理
  • APIサービス
    • キーバリューサービス

当ブログで扱っているRaspberry Piでテレビ電話する方式の状態制御部分が提供できたらゴールです。
(その後は予約サービスとか簡単なドメインを作ってみたい)

プライベート時間で作っていくので完成しないかもしれませんので、ご了承くださいw

cdkでエラー「--app is required either in command-line, in cdk.json or in ~/.cdk.json」が出たときの確認事項

概要

cdkでエラー「--app is required either in command-line, in cdk.json or in ~/.cdk.json」が出たときに確認すべき事項のメモ

確認事項

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+'/*' ],
        }),
      ],
    }),
  }
});

CDKによるLambdaへのコードデプロイについて

概要

CDKを使ってLambdaにコードをデプロイする際のメモ(nodejs版)

説明

InlineCode版

  • ちょっとしたプログラムを手軽にセットする際に便利
  • 4096文字の制限があるので大作には向かない
  • 第一引数に流し込んだ文字列をindex.jsにしてくれる
  • nodejs12.xでは使えない(投稿時の確認では「Inline source not allowed for nodejs12.x」エラーが出る)
import lambda = require('@aws-cdk/aws-lambda');
import fs = require('fs');

new lambda.Function(this, "inlineExample", {
    ...
    code: new lambda.InlineCode(
        fs.readFileSync(`${__dirname}/inline-test/example-inline.js`, {encoding: "utf-8"})),
    ...
});

AssetCode版

  • 指定したパス以下をzip圧縮してアップロードしてくれる
  • 対象のパスにindex.jsを入れておく必要あり
    • index.jsを入れ忘れるとハンドラを定義していても「Runtime.HandlerNotFound: index.handler is undefined or not exported」になる(※index.jsである必要は無いが、ハンドラが別ファイルにある場合はhandlerを正しく設定してあげる必要あり、例えば「lambda/hello.js」に「exports.handler」の記述がある場合はhandlerに「lambda/hello.handler」をセットする)
import lambda = require('@aws-cdk/aws-lambda');

new lambda.Function(this, "assetExample", {
    ...
    code: new lambda.AssetCode(`${__dirname}/asset-test`),
    ...
});

vueのルートとなるパスを変更する方法

概要

vueはデフォルトで'/'をルートとして構成されるが任意のパスをルートとしてリンクが生成されるようにする際のメモ

やり方

vue.config.jsで下記のようにするだけ

module.exports = {
    publicPath: "/vroot",
};

こうすると http://localhost:8080/vroot がトップページになるようにリンクが構成される

公式ページにちゃんと書いてあった(検索キーワードが至らなく辿り着かなかった・・・)

cli.vuejs.org

ちなみにpublickPathを"./"にすれば相対パスになるので配置先のパスを気にしなくてよくなる。