iii threetreeslight

May 29, 2018

Develop GAS on local

業務改善のためにGAS (Google Apps Script) は書かせません ただ、script editorを使ってweb上でデバッグするのは少し効率の悪い作業です。 また、テストを記述することもできません。 そのため、localで如何にgoogle apps scriptを開発するべきか考えをまとめました。 manage and deploy google apps script by clasp Collaborating with Other Developers は必読。 localでgoogle apps scriptを管理するために google/clasp を利用します。 Claspはgasをgitのようにgasのversioning、push/pullなどをサポートします。 Prepare to use clasp Then enable Apps Script API: script.google.com/home/usersettings install clasp sudo npm i @google/clasp -g OAuth loginする。このとき、以下の通りownkey optionをつけて手元に持ってくる必要がある https://github.com/google/clasp/blob/4bc1e32d742e686532d4d51633b59e7c091dba53/index.ts#L766 * Note: to use this command, you must have used clasp login --ownkey clasp login --ownkey 既存projectを管理するための準備をする ... Read more

May 27, 2018

Study to collect container metrics with grafana and prometheus

kubernates環境下へのrolling updateまで自動化なんとなできました。 続いては監視です。 監視するに置いて何が良いのか、何がdefactとなっていくのかを見据えて選定。 Cloud Native Computing Foundation CNCFにはデファクトになるというロジックに則って、どのプロジェクトを採用するか考えてみる そもそもCNCFとは? The Cloud Native Computing Foundation builds sustainable ecosystems and fosters a community around a constellation of high-quality projects that orchestrate containers as part of a microservices architecture. うん。よくわからない。 個人的にはcontainerを利用したサービス運用に関わる様々なものの標準化の流れを作っている理解です。 その中でmonitoring toolとなるとprometheus。 というわけで、prometheusをmonitoring toolとして利用します。 また、prometheusのweb uiはchart表現力が貧弱なので、chartの表示にはgrafanaを利用していきます。 What is prometheus Prometheus is an open-source systems monitoring and alerting toolkit originally built at SoundCloud. Since its inception in 2012, many companies and organizations have adopted Prometheus, and the project has a very active developer and user community. ... Read more

May 26, 2018

Automate build image and rolling update on kubernates

もろもろ環境が整ったところで、ciでのimage build and push と kubernates上で稼働するcotainerのrolling updateを行う。 Automate image build and push multi-stage buildを使いたかったので組み込みつつ、ci上でbuildを通すようにした。 dockerfileはこんな感じ。 FROMalpine:latest AS buildLABEL maintainer "threetreeslight"LABEL Description="hugo docker image" Vendor="threetreeslight" Version="0.1"ENVHUGO_VERSION 0.40.1RUN apk update \ && apk upgrade \ && apk add --no-cache ca-certificates curl \ && update-ca-certificates \ && cd /tmp \ && curl -L https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_Linux-64bit.tar.gz -o ./hugo_${HUGO_VERSION}_Linux-64bit.tar.gz \ && tar xvzf ./hugo_${HUGO_VERSION}_Linux-64bit.tar.gz \ && mv /tmp/hugo /usr/local/bin \ && rm -rf /var/cache/apk/* \ && rm -rf /tmp/* /var/tmp/*COPY . ... Read more

May 19, 2018

publish blog on kubernetes with ingress

gcs上での展開が完了したのと、gcpでのloadbalancingも含めて大体わかってきたので、このblogをgkeを利用してcotnainer運用してみようと思う 構成 多分こんな感じになるだろうと考えて作業 forwarding rule <-> target proxy <-> url-map <-> backend-service <-> node ip <-> pod Create blog image 展開するためのcontaienrを作成する。 まずはnginxまわりを設定 nginx.conf volumeを圧迫しないように、error_log, access_logを /dev つなぎこむ user nginx; worker_processes 1; error_log stderr info; pid /var/run/nginx.pid; events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /dev/stdout; sendfile on; keepalive_timeout 65; include /etc/nginx/conf.d/*.conf; } blog. ... Read more

May 13, 2018

support https access to blog with loadbalancer

GCPを触れば触るほどmodule化されているんだなぁと関心。 GCS単体ではhttpsアクセス出来ないので、前段にloadbalancerを噛ませてhttpsアクセスできるようにしてみる。 構成 GCPのloadbalancerはawsとだいぶ違う。 そのため、全体像を事前に理解しておくために コンテンツ ベースの負荷分散の作成 をやっておくと良い。 出典: コンテンツ ベースの負荷分散の作成 今回はGCSへ転送するので、backend-serviceではなくbackend bucketを利用します。 IP <-> forwarding rule <-> target proxy <-> url-map <-> backend-buckets <-> gcs AWSとだいぶ異なるため、それぞれの構成要素がawsでいうと何に当たるのかをマッピングして説明します。 IP entrypointとなるIP address. gcpから払い出しておく必要がある AWSのように作成されたloadbalancerに勝手にentrypointが出来るものではなく、IPを払い出し明示的に割り当てる必要がある forwarding rule 指定されたip, portへのrequestを何処に転送 (target proxy) するか決まったルール 特定のloadbalancerに必ず紐づくものではない。 AWSでいうとalbのlistenerあたりが近い。また、security groupが無いということ。 target proxy URL マップにリクエストの経路を指定するターゲット HTTP プロキシ。そのため、https access時の認証を行うssl証明書はtarget proxyが保持する AWSでいうlistenerが近い。 url-map リクエストの URL を解析し、リクエスト URL のホストとパスに基づいて、特定のバックエンド サービスに特定のリクエストを転送。 AWSでいうとtaget groupが近い backend-bucket url-mapをもとに決定された転送先。 backend-serviceを利用するとインスタンスのhealthcheckまでを責務を持つものに成る。 url-mapとbackend-bucketをあわせることで、awsでいうtarget groupになる。 Creating Content-Based Load Balancing gcs bucketにアクセスをつなぐbackend bucketを作成します。 事前に blog. ... Read more

May 13, 2018

Generate SSL/TLS certificate with let's encrypt

gcpにはaws acmに該当するサービスがないので、証明書を作成しなければいけない。 そのため、Let’s encryptを利用した証明書発行を行う。 Let’s encryptとは https://letsencrypt.org/about/ Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. It is a service provided by the Internet Security Research Group (ISRG). 通信の安全を担保するためにも全ての通信がssl/tls ptorocolでの通信する必要がある。 そのためにも、free and automatedなCAっていうのが大事。それを提供しているのがlet’s encryptedという認識です。 let’s encryptによる証明書の発行にはshell accessとそうでない方法ががあり、shell accessを前提としたcertbot ACME clinetを使うと良いよということのようだ。 https://letsencrypt.org/getting-started/ We recommend that most people with shell access use the Certbot ACME client. It can automate certificate issuance and installation with no downtime. ... Read more

May 7, 2018

Publish blog on GCS

とりあえずある程度形ができたので、publishしていきたいと思う。 hosting static website on gcs とりあえずgcsでstatic site hosting出来るだろうと思ったら、あった。 https://cloud.google.com/storage/docs/hosting-static-website まずはdomainの所有権をgoogle search consoleから取得しなければいけないというところにgoogleっぽさを感じた。 AWS S3ではbucket作ってcnameで飛ばせば良いだけなのに対し、GCP上では結構違う domain nameを含むバケットの場合は、ドメインの所有権認証をする https://cloud.google.com/storage/docs/domain-name-verification#verification googleっぽい valueに c.storage.googleapis.com. を指定したCNAME DNS recordを作成する GCSはGCP内からのアクセスを前提としたストレージであり、public endpointが最初から提供されていないということかな? 公開endpointは c.storage.googleapis.com にアクセスするとproxyされるという妙 あとはgcs bucketを作って、コンテンツをuploadし、各ファイルにread権限を付与 静的サイトのエンドポイントにアクセスしたときに表示するページやエラーページを指定 一旦公開できた。

May 6, 2018

Make plugins available for mitame

dockerあるしもうlocalのnodeを切り替える必要ないよなーと思ったためにnvmをやめようと思う。 それにともない、mitame側でnpm pakcage のglobal installが出来るようにしてみた https://github.com/timakin/itamae-plugin-resource-npm/pull/1 初めてmitamaeのpluginを書いたのでdesiredとcurrentの作りはいいなぁと感じた次第でした

May 2, 2018

Refine intercom UI

Reproではテクニカルなサポートにintercomを利用している。 最近UIもrenewalされたが、まだ痒いところに手が届いていない状況であることは否めない。 そういうところを直すために、 refine-intercom というextentionを作った。 Automatically ellipsis email history チケット管理の観点からも、なるべく社内外からの問い合わせ回答する場所をintercomに一本化しており、その問い合わせ経路の一つにemailがある。 このとき、emailでやり取りしていたお客様から、テクニカルな質問があるときは途中からtechnical supportにバトンタッチされる。 これはとても良いことなのだが、大きな問題はemailの履歴である。 この履歴がintercomの会話パネルを全て埋め尽くす。いくらスクロールしても終わらない状態。とはいえ、読みたいときもゼロではない。 こういう状態が続いていたわけです。 このような問題を解決するために、emailの履歴とみられる情報をconversation上に見つけたらdetail tagで括って、必要となるまで非表示にしてしまうようにしました。 ここらへんはintercomさんでうまくやってくれるとユーザービリティ高いのになぁ Expand conversation window チャットツールをディスプレイ縦置きした状態で見る人は少なからずいるはずで、例に漏れず私もその一員である。 このとき問題なのが、full HDサイズのディスプレイを縦置きすると横幅が1080になる。 コードを書くときはこれで問題ないのだが、チャットする上では、こう会話ペインがぎゅっと小さくなるわけだ。 そうしたときに、常に見たいわけではない情報を隠したい。 このために右ペインのペルソナ情報を隠すボタンを作った。 今思うとキーボードショートカットを割り当てたほうが良かった気もしている。 Essential tag validator 単純に問い合わせを受けて処理するだけなら問題ないのだが、問い合わせの機能や種別、処理時間を分析したいニーズは往々にあると思う。 そういうニーズに対してintercomは正直まだまだ行けてなくて辛い。 なので、会話にタグ (e.g. feature-push など ) を付けてzendeskやgoogle spreadsheetに記録して分析している。 そういうときに問題と成るのが、分析軸となる担当者のtagのつけ忘れである。 この問題に対応するために、必要なtagのprefixをchromeのstorageに記録しておき、最初のconversationのタグ情報をチェックするようにした。 こうすることで、タグつけ忘れが見える化され、問題が解決されることを祈る。 あっタグ情報はstorageに記録以外にも、gistなりs3なりにおいたファイルをパースして取得するようにしておけば、各位の設定漏れもなくなるから良いのかなぁ

April 30, 2018

build hugo on ci

deployに備えてblogのci環境を構築する。 stackshare - ci を見る限りcircleciがshare的にも無難。 とはいえ、使い慣れたツールっていうのも味気ないが、将来的にはconcourse ci に載せ替えるとしてとりあえずはcircleciを利用する。 circleciで準備されたimageを利用するのだが、その中でやれ何かをinstallするとか辛いし時間がもったいない。 速さは正義なので、imageをpullしてcodeをmountし、buildするという流れが望ましい。 create docker image まずhugoが稼働するdocker imageをつくる。 世にあるやつがメンテナンスされていないのと、host側の設定をcopyするようなものだったので、動きやすさを含めて自分で作成。 https://hub.docker.com/r/threetreeslight/docker-hugo/ executer type どうするか? executerをdockerで動かしたときに、container内にcheck-outしたfileをどうやってmountするか。 circleciを見る限りvolumeを共有することは困難である。そりゃそうだよね。 https://circleci.com/docs/2.0/executor-types/#using-docker とはいえmachineを使うと Start time が 30-60 sec という。 このリードタイムは許せない。 Remote Docker そこで見つけたのがRemote Dockerという機能 https://circleci.com/docs/2.0/building-docker-images/ To build Docker images for deployment, you must use a special setup_remote_docker key which creates a separate environment for each build for security. This environment is remote, fully-isolated and has been configured to execute Docker commands. ... Read more