名もなき未知

エンジニアリングとか、日常とかそういうのをまとめる場所。

Github Actionを使ってFirebaseにデプロイしたい

改訂新版 Vue.jsとFirebaseで作るミニWebサービス (技術の泉シリーズ(NextPublishing)) | 渡邊 達明 | 工学 | Kindleストア | Amazon を今更ながら触りつつ、勉強している。

そこでFrebase Hostingにデプロイすることを手動でやっていたが、ちょい足しポイントでCIでデプロイしてみようみたいなものがあり、そこで試行錯誤していたときのメモ。

組み合わせとか

書籍に出てきたとおり vue-cli は使っているが、個人的に yarn を使っているので、パッケージマネージャーは yarn でやった(あんまり変わらないけど)。

できたもの

とりあえずこれで動いた。環境変数は firebase-tools でやったらとれた。

name: Node CI

on:
  push:
    branches: [ master ]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [12.x]
    steps:
    - uses: actions/checkout@v2
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - run: yarn
    - run: yarn run build
    - name: replace index.html
      run: cp index.html dist/
      shell: bash
    - name: deploy to Firebase Hosting
      uses: w9jds/firebase-action@master
      with:
        args: deploy
      env:
        FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}

結構見様見真似なので、書き方微妙なところはあるカモ。

見たところとか

まとめ

GitHub Acitonsで環境変数の入れ方とか含めて学べたのでとても良かったです。あとは人間が手でやってもFirebaseへのデプロイ簡単なんですが、それを自動でできるのはいいなあという感想です(それについても色々学びがあったので他の記事で触れたい)

繰り返し作業の自動化をしていくのは活動時間の確保につながるので、ガンガンやっていきたいですね。

今更ながら「ゼロからわかる Amazon Web Services超入門 はじめてのクラウド」を読んで実際に動かした

普段プログラムメインで書いているので、あんまりAWS周り真面目にやってなかったのですが、とりあえず動かして触ってみることにしました。

どんな本

セールで買って放置してたので、内容は若干古めかも。とはいえ、基本的なサービスである、EC2, S3, RDS, Route 53などを触りながら学べるのでまあ、包括的に第一歩として触れるなら… という感じはします。

なお、本書内の WordPress を動かすところですが、Amazon Linux で入るデフォルトのPHPバージョンが5.4とかなり古く、現行のWordPressが動かない問題があります。それ含めると普段開発してないような人が1冊目に読むにはやや辛いのかなという感想があります。(公式のチュートリアルも充実しているので、まずそちらを触るのが良さげかも)

というか PHP のバージョン情報、正誤表に載ってた(今気がついた)

gihyo.jp

本の内容

章情報は下記の通り(公式サイトより引用)

  1. Amazon Web Servicesとは何か
  2. AWSをはじめよう
  3. Webサイトを公開しよう
  4. LAMPサーバーでWordPressを動かそう
  5. データベースを活用しよう
  6. 固定IPアドレスドメイン名を使おう
  7. 安全な通信を使おう

1章「Amazon Web Servicesとは何か」はもはやネット情報の情報等で十分補足可能だと思うので、ここは飛ばして2章以降の感想を書いていく。

2章 AWSをはじめよう

アカウント取得とかの話だったのですが、どちらかといえば普段遣いするアカウントはちゃんと分けようね、っていう思想を知りました。(ユーザー用のIAM切っとけ、って話)

確かに普段操作するアカウントが常にAdminみたいな状況は良くないのかもなあとか。ただやり方自体は Serverless でAPI立ててたときにやっていたのでスムーズに終了。

ユーザー用のパスワードがどこにあるのか一瞬混乱しましたが、APIキーとかが入っているCSVファイルに一緒に書いてありました。ハマったのはそこくらい。

3章 Webサイトを公開しよう

S3を使います。まああとのRoute 53とうまく組み合わせれば、それだけでWebサイトの公開できてしまうんだなあと思ったり。(個人的にそれやるならNetlify + ナニカ、なのでその用途で使いたいことがあまり思い浮かびませんが… Google Driveの代わりとかでコンテンツ配信するとか?)

ハマリポイント1 アクセスポリシー設定

S3のアクセスポリシーを公開にするところがあったのですが、ここでローカルで正しそうなファイルを作ってもうまく行かず… だったのですが、Generatorがあるようです。なのでこれを使いましょう。

https://awspolicygen.s3.amazonaws.com/policygen.html

Version 情報を今日の日付にしたかったのですが、何故かうまくいきませんでした。謎。AWS側のドキュメントはあまり漁っていないのですが、そっちの方に書いてあるのかな。

ハマリポイント2 Content-Type

HTMLを日本語混じりで投稿したのですが、なんか文字化けしました。Content-Typeに正しくUTF-8と入れておかないとコケる模様。対処方法としては2つあります。

  • HTML のヘッダーに、 <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/> を記載しておく
  • S3側で、index.htmlのコンテンツタイプを変更するところにいって、同じように charset=utf-8 を指定する

前者の対応のほうが固いでしょう。後者は index.html をUploadし直すたびに設定が必要っぽく(これは僕の勘違いの可能性もあるが、見てる限りだと毎回 Content-Type が text/html とリセットされていた、文字コード別にすれば回避できる可能性はあるが…)厳しいので。

どちらにしろ前者対応なら、ローカルのディレクトリ全部検索するとかで文字コード明示的に探せるしいいんじゃないんでしょうか…(S3とかでそれ簡単にできるの? は少し疑問)

S3用のツール

Mac、個人で触るのなら無料で使える Cyberduck でとりあえず良さそうな感じです。

ググっているとホームページからDLしたほうが良い、とあるのでホームページからDLすると良いです。

https://cyberduck.io/

4章 LAMPサーバーでWordPressを動かそう

EC2を使います。主に入れるのはこのあたり。

これを本に沿ってガチャガチャ設定していくとWordPressが動きます。すごい。が、ここかなり手打ちの箇所が多くて辛いので、2度目以降やるならなんかもう少し簡単な方法(テンプレート、みたいなのが見えたのでそういうの使ったり、ツールとかでガチャガチャやるのが正解なのかな?)でやりたい。とにかく人間がやるには手順が長すぎると思いました。

接続周りの pem ファイルは実態が RSA秘密鍵だったので、 chmod 400 hogehoge.pem してから ssh ec2-user@あいぴーあどれす -i hogehoge.pem で普通に繋げました。

ハマリポイント1 PHPバージョン

何も見ずに進めていくと、PHP5.4がインストールされ、現行WordPressの最低要求バージョンを満たさないので、無事に虚無なページへと移動します。公式ページ見てれば気がつけたのですが、見ていなかったのでゴリゴリ進めました。このあたりを見て対応していきました。

これに気づかず、インスタンスを一回削除して入れ直したので辛かった。

ハマりポイント2 設定周り

MySQLの設定をひたすらしていたが、これは結構書くのがめんどくさいので、こういうのりでやりましたっていうSQLを貼っておく。。。チラチラタイポして大変だった。

update mysql.user set password=password('mydbpassword') WHERE
user = 'root'; FLUSH PRIVILEGES;
create user 'wordpress'@'localhost' IDENTIFIED BY 'mypassword';

create DATABASE wordpressdb;
grant all privileges on wordpressdb.* to 'wordpress'@'localhost'; FLUSH PRIVILEGES;

5章 データベースを活用しよう

RDSを使います。インターフェース周り以外でハマったところはなかったです。(もともと複数ページに分割されていたものが1ページになっているっぽい)

EC2のセキュリティーグループの設定で MySQL/Aurora のアクセス権限とか持たせていなかったので、なんで接続できないんだろう? と若干戸惑ってましたが、問題なく最後までやれました。(ただ、接続できないときにめっちゃ時間かかってNG(普通のタイムアウトっぽい)、みたいな感じなのでそこはなんか、即遮断みたいな感じだと嬉しいなと思った)

6章 固定IPアドレスドメイン名を使おう

Elastic IP を使う話でしたが、実はEC2やってるときにすでに設定してて、うん、知ってる… ってなりました。

その後はRoute 53でドメインを取得してみて、Aレコードを設定し・・・ というのをやっていたのですが、DNS側への反映が遅いのか、設定がおかしくてうまく動いていないのかわかりませんでしたが、結局S3、EC2両方とも見えませんでした。

まあここはリベンジ、そのうちする。

7章 安全な通信を使おう

ALBやCouldFrontを使います。ALBはEC2のために、CouldFrontはS3のために、ですかね。証明書自体はAWS Certificationで発行して、ALB、CloudFrontに設定していくというながれです。

まあ、ここもポチポチしていくだけなんですが、6章のRoute 53の設定をミスしている?ためかここでも正しく表示されなかったのですよね。うーん、わからん。

とはいえSSL通信するための仕組みが簡単に用意されているのはいいかなあと思います。

まとめ

実際に触ってみて、ポチポチだけでサイト構築ができてしまうのは良いなあと思う一方、エンジニア的には再現性は?とか気になるところで、やっぱり構成コードで管理したいよねっていうのが非常にわかる、という感じです。

他にも色々機能があるのでとりあえず残りのチュートリアル触ってみる → Route53のリベンジとかできたらCodeでの構成管理しようかな、とやってみたいことのロードマップは定まりつつあります。

やって価値がなかったかというと微妙なんですが、これまである程度開発してきた人でかつAWSあまり知らない人(こういう人は今後減っていく傾向な気はしていますが…)が、サラッと読むには向いているのかなと思います。今から初心者がやるには少しハマりどころが多いような気もする。

というわけで今年は少しづつこういうのも使えたらいいなーと思って、勉強していきます…。

DevSumi2020のブースを見てて思ったこと

長いので別記事にしました。

ブースの感想

実は会社でもブース担当としてたまに突っ立っている時があるので、参考にしようかなと思っていくつかの会社を回った。

自分の中でブースに取り入れたいなと思ったのが、ボードでした。回った中でもいいなーと思ったのがアトラシアンさんとFindyさんでした。

アトラシアンさんはブースの使い方が斬新で、もはやボードのためにブースが存在していました。物が大きいとなんだか気になってくるので、うまいやり方だなと思いました(以前、自分の中でポスターをブースの後ろに貼るなどを考えていましたが、これは前面に内容を出せるので見せ方として面白いなと思いました)。ブースでこういう事やっていいよっていうのが許されるなら、自分の会社でやっているサービスのアンケート的な展開もできるのかもしれませんね。ここでは開発におけるプロジェクト関係の課題とか(アジャイル?だったかもしれない)がはられていて、悩みの共有や発見がなされていたイメージです。時間があればもう少しゆっくり回りたかった…。

Findyさんはよくある感じのボードでしたが、その貼った項目に対してなぜ?ってところを深く聞かれながら採用課題について話したのが経験としてよかったように思いました。ただ単に貼って、だけじゃなくて話をしっかりすることで印象に残りやすく、また(エージェント採用を専門にしていることもあり)採用市場についても新たな発見ができ、とても良い経験ができたと思います。ここに関しては、こういう市場がある、その市場はこうだ、というのを丁寧に話せたのがボードというコミュニケーションの道具を使って円滑にできたことが良い経験につながっているように思います。

まとめ

ノベルティも大事ですが、それ以上に印象に残るのは会話や人だと感じました。良き人でありたいものです。

また、クローズドにすればいいアンケート項目(個人情報が含まれるとか)と、オープンにすれば良いアンケート項目の使い分けと見せ方が大事なのかなと思いました。オープンにすれば良い項目についてはボードにしたり、ポスターに貼ったりしてわかりやすい形にできるといいですね。

イベント協賛する際は今回考察したことをもとに改善できればと思います。(その結果について本ブログで語られるかは未定ですが)