Go lang で SSL チェックするプログラム

書いた。

github.com

感想

badssl.com を使って TLS Version のテストケース書くなどした。

大量にリクエストを送って動作確認する実装なので、テスト実行するときは気をつけたい。

Go言語による並行処理

Go言語による並行処理

GKE 上で Pub/Sub 動かすサンプルアプリ

コンテキスト

今年は GCP を触っていくと決めていたのにしばらくぶりになってしまった。
前回が半年以上前。

Azure 系エンジニアから見た GAE 〜Google App Engine編〜 - ぐだぐだ言ってないでコードを書けよ、ハゲ。

本題

今回はサービス評価ではないが、以下のサービスを触っているという近況報告。

k8s 上の Deployment で Pub/Sub の Subscriber を常駐させつつ、CronJob で Publisher を動かすサンプルアプリを書いた。

github.com

感想

k8s はだんだんしっくり気始めて、基本的な概念理解からようやく Secret や Config など現場で使う技術に手が出始めた段階。
やはり実サービスで自分で使っていかないと身につかない。
デバッグやアップデートどうするんだっけ、という現場で当たり前のテクニックがないとマズイなと思った次第。

所感としては、特につまづくことがなかったので、よく出来てるなあという印象。
公式を見て順番に理解していけば進められる。

Kubernetes Documentation - Kubernetes

YAML Hell については Kustomizeがkubectrlに統合されていくらしいので、はじめから使っていけばいいかなという感じ。

ほか

個人サービスで使っていくことで理解が深まりそうなので、どのクラウドで使うかはわからないがいろいろ試していきたい。

Kubernetes完全ガイド (impress top gear)

Kubernetes完全ガイド (impress top gear)

SharePoint Online の REST API を PowerShell から叩いてハマったことへの対処

SharePoint Online の REST API を PowerShell から叩いてみる - からめもぶろぐ。
MVP の方の記事をほぼそのまま試していましたが、多少ハマったのでその補足を備忘録として残します。

グループのタイトルの取得

サイトのタイトルは元記事の通り、以下。

$uri = $resourceUri + "/_api/web/title"

グループのタイトルは以下。

$uri = $resourceUri + "/sites/(group_name)/_api/web/title"

類推した通りに動きます。

グループのドキュメント一覧の取得

サイトのドキュメント一覧は元記事の通り、以下。

$uri = $resourceUri + "/_api/web/GetFolderByServerRelativeUrl('/Shared%20Documents')/files"

グループのドキュメント一覧は以下。

$uri = $resourceUri + "/sites/(group_name)/_api/web/GetFolderByServerRelativePath(decodedurl='/sites/(group_name)/Shared%20Documents')/files"

パスの指定が重要ですね。

一度許可したアクセス許可を削除する

SharePoint の話題ではありませんが。
Azure AD 内で登録したアプリケーションに対してアクセス許可をしますが、許可した対象によって登録される先が違います。

f:id:khei-fuji:20181011165541p:plain

組織の代理として同意する にチェックがある場合は Azure AD、ない場合は個人の Office365 に登録されます。

参考記事

ひと目でわかる SharePoint Server 2016

ひと目でわかる SharePoint Server 2016

Azure DevOps Pipelines で Go の Docker コンテナを Heroku に継続的デプロイする

kheiakiyama.hateblo.jp

フロント部分は Nuxt.js で作っているアプリですが、バックエンドのAPIは Heroku にデプロイすることにしました。
どうせなら Firebase にデプロイしたかったのですが Firebase Function はまだ Go や Docker に対応していません。残念です。

実装方法

Heroku

Rails アプリを動かす PaaS と思ってましたがいつの間にか Docker コンテナを動かせるようになってました。

コンテナを動かすための手順はこのあたりにあります。
Container Registry & Runtime (Docker Deploys) | Heroku Dev Center

Dockerfile を書く上での制約がいくつかあるので気をつけたいところです。
引っかかりそうな部分は下記2点あたりです。

The web process must listen for HTTP traffic on $PORT, which is set by Heroku. EXPOSE in Dockerfile is not respected, but can be used for local testing. Only HTTP requests are supported.

(意訳)EXPOSE は無視します。$PORTトラフィックを流すのでよろしくね。

CMD is required. If CMD is missing, the registry will return an error CMD will always be executed by a shell so that config vars are made available to your process; to execute single binaries or use images without a shell please use ENTRYPOINT

(意訳)CMD は必ず指定してね。

Azure DevOps Pipelines

kheiakiyama.hateblo.jp

上の昨日の記事にも書きましたが DevOps Pipelines ではYAMLファイルで設定できます。
Agent-pool は Hosted Ubuntu 1604 を使います。

azure-pipelines.yml

pool:
  vmImage: 'Ubuntu 16.04'
  
variables:
  HEROKU_API_KEY: YOUR_API_KEY
  HEROKU_APP: YOUR_APP_NAME

steps:
- script: |
   #!/bin/bash
   heroku container:login
   heroku container:push web --app $HEROKU_APP
   heroku container:release web --app $HEROKU_APP
    
  displayName: 'deploy to heroku'

Heroku CLIHosted Ubuntu 1604 にインストールされているのでスクリプト一つで済みます。
Heroku CLI の認証は環境変数HEROKU_API_KEY があればそれで行えるので、 heroku auth:token とかで取得、適宜作成します。
おそらく Secret 用の指定方法はあるのですが、まだ調べてないのでそれはまた今度。

heroku container:pushdocker build && docker push が走るようで、若干気持ち悪さがあります。
タグを意識させないためでしょうか。

感想

ということで無料の範囲で DevOps パイプラインまで作成することができました。
サクッと Docker コンテナの PaaS が使える Heroku はやはりよいですね。

久しぶりに使ったので変なところにハマってしまいましたが無事動きました。

これで Nuxt.js のバックエンドAPIが動かせそうです。

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Azure DevOps Pipelines で Nuxt.js アプリを Firebase に継続的にデプロイする

kheiakiyama.hateblo.jp

Nuxt.js で書いたアプリですが、デプロイが煩わしい状態でしたので、最近話題の Azure DevOps を使って継続的デプロイを設定しました。

Azure DevOps Pipelines について

まずは公式リンク。

azure.microsoft.com

なぜ Azure DevOps(Pipelines) を使うかというと、プライベートリポジトリを使う場合の CI/CD サービスで Travis CI や CircleCI を使うとそこそこの費用が発生するためです。
(私は GitHub はプライベートリポジトリを使っています)
ギョーム開発であれば有償サービスを使うべきかとは思いますが、Azure DevOps Pipelines は月1,800分の無償枠があります。(2018/9/14 現在)
個人開発で何かを作るにはこの枠を有効に使えるのではないでしょうか。

実装方法

Azure DevOps Pipelines

DevOps Pipelines では GUI で設定する方法とYAMLファイルで設定する方法がある。
GUI で作ったものは後からYAMLを確認できるので、まずは GUI から入るとよい。
ここでは結果のみ書く。

以下の yamlリポジトリ直下に置き、Agent-pool は Hosted Ubuntu 1604 を使う。

azure-pipelines.yml

pool:
  vmImage: 'Ubuntu 16.04'
  
variables:
  firebaseToken: '********'

steps:
- script: |
   #!/bin/bash
   npm install firebase-tools firebase-functions firebase-admin
  displayName: 'Install firebase-cli'

- task: Npm@1
  displayName: 'npm install'
  inputs:
    verbose: false

- script: |
   #!/bin/bash
   npm run build
   npm run copyassets
   node_modules/.bin/firebase deploy --token $(firebaseToken)
  displayName: 'Run npm deploy'

パイプライン内では npm のグローバル環境下に Firebase CLI をインストールする権限がないため、firebase はローカルにインストールしています。
そのため firebase deploy はパス指定して動かす苦肉の策で実行しています。

このYAML についてのドキュメントはまだまだ充実してません。
サンプルコードが以下に紹介されており、GitHub を漁ると iOSAndroid のサンプルも見つかるので参考になれば。

Create your first pipeline | Microsoft Docs

Node 部分

package.json

  "scripts": {
    "dev": "nuxt",
    "build": "npm run clean && nuxt build",
    "clean": "rm -rf dist && rm -rf functions/nuxt",
    "deploy": "npm run build && npm run copyassets && firebase deploy", // for local only
    "start": "nuxt start",
    "generate": "nuxt generate",
    "lint": "eslint --ext .js,.vue --ignore-path .gitignore .",
    "precommit": "npm run lint",
    "copyassets": "mkdir -p dist/assets && npm run copydist && npm run copystatic",
    "copydist": "cp -R functions/nuxt/dist/ dist/assets",
    "copystatic": "cp -R static/ dist"
  },

Nuxt.js 部分

nuxt.config.js

module.exports = {
  buildDir: "functions/nuxt",
  build: {
    publicPath: "/assets/",
  }

感想

Microsoft-Hosted Agent の Docker Image に Firebase CLI を入れる PullRequest 書いたら通るのでしょうか。
後で気が向いたら試してみようと思います。
GitHub - Microsoft/vsts-agent-docker: Visual Studio Team Services (VSTS) Agent Docker Images

Self-Hosted Agent を作るのは結構敷居が高い印象あるので、Travis CI のように Agent に使う Docker Image を指定できると 一番理想的です。

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.js を Firebase Hosting, Function で SSR する

コストかけずに始めていざとなったらスケールするインフラとして Firebase が気になっている。
そしてWebのフロントエンドで疲弊しないための選択肢として Vue.js が同じく気になりだした。
SPA(SinglePageApplication)やるとSSR(ServerSideRendering)がサービスの性質によっては必要になるので、そこをどう実現するのかを試してた。

参考資料

Nuxt.js は公式ガイドが非常に充実していて、日本語もある。

はじめに - Nuxt.js

公式が一番の近道。
あとは参考にすべき実装は Qiita やブログではなく、以下のリポジトリが一番わかりやすかった。

github.com

解説

まず通常の静的サイトホスティングであれば Nuxt.js の公式に Firebase へのデプロイ方法が書いてあるので、SSRが不要であれば以下のドキュメント通りに実現するのがよい。

ルーティング - Nuxt.js

SSRをやる場合、フロントのURLは Firebase Hosting から払い出される xxx.firebaseapp.com になるが、Hosting するのはアセットのみで、各ページのルーティングURLへのアクセスは裏側の Functions にリライトする形となる。
上にあげたリポジトリのコードを読んでいて、この点に気づくまでに時間がかかった。。

以下の Firebase ドキュメントにリライトの適用ルールについて記載されている。

Customize Hosting Behavior  |  Firebase

他にやること

SSR は検索サービスにページをインデックスしてもらうのが目的の一つだと思う(クライアントの負荷軽減など他にもあるが)が、サイトマップの生成などやることは他にもありそうだ。

感想

Vue.js ならびに Nuxt.js は全部入りって感が強く、比較すべきではないが React やWebPackなどでどう組み合わせるか考えるのが億劫な人にはちょうどいいソリューションだと感じている。
自分にとってはフロントエンドの裏側に API サーバーを Go で書きたいとかやりたいことがそっち方面に広がっているので、学習コストがそこそこに済むものを使っていきたい。
とはいえやっていくうちに悪いところも見えてくるに違いない。

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Nuxt.jsビギナーズガイド―Vue.js ベースのフレームワークによるシングルページアプリケーション開発

Firebase をざっくり理解するためにサンプルアプリ書いた

Firebase を使う機会があり、どんなものか理解するためにやったことを書いておく。

把握する

Firebase の公式サンプル を見ると、ほぼすべての機能を網羅している FriendlyPix というアプリがあったので、これのコード・ドキュメントを読み込むことにした。

Friendly Pix

iOS, Android をほぼ書いたことがないため、Web に対応されていたのが大きい。

github.com

使って理解する

コード読むとわかった気になるが、書けるようにならないと理解したとは言えない。
なので上であげた fiendlypix-web をベースに fork したアプリを書いた。

ちょうと GitHub のコントリビュートの度合いが可視化できると面白いかなと思ったので、それらしいもの。

Repos Presense

ドメイン取るほどでもないので雑に作って雑に公開。

主な変更点は

  • GitHub 認証に変更
  • 写真のファイル保存機能を削除
  • GitHub のコントリビュート数を取得、自分のコントリビュートが何番目かを表示するように変更
  • アプリ名称変更に伴うドキュメント類の書き換え

これらによって、database の具体的な設計方法や Authentication の手軽さなどがわかった。

はてなブログにリンク貼って気づいたけど、meta データ変更してなかった。

余談

最近は Qiita ややってみた記事を読むことが減ってきて、公式ドキュメントを重視するようになってきた。
はてブのテクノロジー記事追っても PodCast 聴いても技術は身につかないし、手を動かしていきたい。

WEB+DB PRESS Vol.105

WEB+DB PRESS Vol.105

  • 作者: 小笠原みつき,西村公宏,柳佳音,志甫侑紀,池田友洋,木村涼平,?橋優介,大塚雅和,飯塚直,吉川竜太,末永恭正,久保田祐史,浜田真成,穴井宏幸,大島一将,桑原仁雄,牧大輔,池田拓司,はまちや2,竹原,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2018/06/23
  • メディア: 単行本
  • この商品を含むブログを見る