Kekeの日記

エンジニア、読書なんでも

Digdagでワークフローを宣言的に書く!

本記事

私は、いくつか家内サービスを運用しています。 例えばCloud FunctionsとCloud SQLを使った「家計簿」を家族全員が使っていますし、自宅に「監視カメラ」をおいてLineBotで適宜確認できるようになっています。

無料枠を使い回しているのでデータ移行が定期的にありますが、そのときによくEmbulkを使っています。

非常に短い備忘録ですが、以下にまとめています。

www.1915keke.com

この記事は短すぎて適当に見えるのですが、それくらいシステムは簡単だったことが印象でした。

今回はEmbulkと同じくTeasureDataで開発が進められているDigdagを使ってみて、どのような開発のしやすさなのかなど知識を増やしたいと思います。

Digdagについて

一体何をするもの?

https://camo.qiitausercontent.com/9f383de06b4507b7f860521f18dea05734086a69/68747470733a2f2f7777772e6469676461672e696f2f77702d636f6e74656e742f75706c6f6164732f323031362f31312f4469674461675f686f72697a6f6e74616c2e706e67

Digdagとは、トレジャーデータが公開したオープンソースなワークフローマネージャーです

設定ファイルは一般的なYAMLではなくて.digであり、どうやらMapのキーの順番が維持される必要があるかららしいです。

目的としては

  • cron
  • ITオペレーションの自動化
  • バッチジョブによるデータ分析

などを置き換えるために作られています。手作業で行っていた作業を自動化することによって、様々な恩恵が受けられると思います。

特徴

1. 簡単に開発できる

バイナリーをダウンロードすればすぐに開発できます。

周知の如くですが、やはり開発しやすさと開発スピードには相関があり、それはビジネスを進める上でも非常に重要です。

2. 簡単な設定

YAMLによって書かれているため非常に分かりやすいです。

YAMLは広く使われていてCircleCIやKubernetesをはじめとするありとあらゆるものに使われています。

3. 依存関係の解決

依存関係がある読み書きできるワークフローになっています。CrobJobのように時刻で動作するようなものから解放されます。

4. マルチクラウド

Amazon Redshift/S3をはじめBigQuery/ Could Storageやオンプレミスなデータベースからデータを扱えます。

5. 多言語サポート

現在はPythonとRubyをネイティブサポートしています。

データサイエンティストとWeb開発者が協力することができます。

6. エラーハンドリング

ワークフローが失敗してしまったとき、Digdagはロバストなエラーハンドリングを提供します。

7. モジュール性

それぞれのワークフローが再利用可能なものになるようにDigdagはデザインされています。

8. 拡張可能

Pluginによって拡張できるようになっています。自分のオペレータやコントロールフローを定義できる。

9. 管理者UI

GUIによって管理ができるようになっているので、すべてをコマンドラインからする必要がないです。

10. Secretsを管理

DigdagはSecretを安全に管理できるようにできる。

11. Dockerをサポート

DigdagはDockerコンテナに定義されてあるDockerコンテナをサポートしているので、環境に依存せずにタスクをこなすことができます。

12. バージョン管理

Digdagはワークフローをコードとして宣言的に書くことができます。

アーキテクチャ

ワークフローによってありとあらゆるタスクを自動化できます。

タスクはオペレータープラグインを使って定義されます。使えるオペレーター一覧は以下の通りです。

Operators — Digdag 0.9.5 documentation

これからアーキテクチャについて説明していきます。

1. グループによるタスク管理

[http://docs.digdag.io/images/grouping-tasks.png:image=http://docs.digdag.io/images/grouping-tasks.png]

Digdagでは複雑なワークフローを自動化できる一方で、管理をしなければなりません。

しかし、グループという概念でタスクをまとめることができ、直感的にワークフローを理解することが容易になります。

親子の関係であり、グループが実行されるとそのグループに含まれる子であるタスクがすべて実行されます。タスクが成功するとグループが成功したとされます。

2. パラメータ

グループにタスクをまとめることは、タスク間でパラメータを渡すために使われています。

親のタスクはexportすることによって変数をこのタスクに渡すことができます。

3. ワークフロー as Code

「宣言的に書ける」よとうことです。

例えばGithub上にあるワークフローは実際のデプロイされているワークフローをそのまま表していることになります。

逆も然りです。実際のワークフローはGithub上のコードを記述しているはずです。

4. Docker上でタスクを実行できる

Dockerの上でタスクを実行するので実行環境の差分によるエラーなどを防ぐことができます。

例えばDockerを使う場合は以下のように書きます。

_export:
  docker:
    image: ubuntu:latest
    pull_always: true

+step1:
  py>: tasks.MyWorkflow.step1

用語

Task

あまり説明が必要ではないかもしれませんが、アトミックな実行単位です。名前は一意になるようにしなければなりません。

実際に何をするかは定義次第です。

一例としてあげます。

# my_workflow.dig
+load:
  +from_mysql:
    +tables:
      ...
  +from_postgres:
    ...
+dump:
  ...

このようにすると特定のタスクは親のタスクがプレフィックスについた名前で指定されます。例えば+my_workflow+load+from_mysql+tables,+my_workflow+load+from_postgresのようになるということです。

ワークフローを作ってみよう

DigdagをInstallする

まず、以下のコマンドを使用してインストールします。

$ curl -o ~/bin/digdag --create-dirs -L "https://dl.digdag.io/digdag-latest"
$ chmod +x ~/bin/digdag
$ echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc

ここで確認のために

digdag --version

と実行してみてください。

私の場合はFishシェルで実行しているためエラーが出ました。

Failed to execute process '/Users/keisukeyamashita/bin/digdag'. Reason:
exec: Exec format error
The file '/Users/keisukeyamashita/bin/digdag' is marked as an executable but could not be run by the operating system.

これはIssueにもあがっています。

github.com

以下のaliasを登録します。

alias digdag="java -jar ~/bin/digdag"

すると使えるようになると思います。

digdag --version

0.9.31

これで始めることができます。

簡単なワークフローを作ってみる

まず、これまでのディレクトリは以下の通りになっています。

.
└── README.md

そして以下のようにdigdag initコマンドで初期化します。

digdag init hello-world-workflow

すると以下のようなディレクトリ構成になっています。

.
├── README.md
└── hello-world-workflow
    └── hello-world-workflow.dig

また、実際の中身の.digファイルは以下のようになっています。

timezone: UTC

+setup:
  echo>: start ${session_time}

+disp_current_date:
  echo>: ${moment(session_time).utc().format('YYYY-MM-DD HH:mm:ss Z')}

+repeat:
  for_each>:
    order: [first, second, third]
    animal: [dog, cat]
  _do:
    echo>: ${order} ${animal}
  _parallel: true

+teardown:
  echo>: finish ${session_time}

これを実行するにはdigdag runコマンドを実行せればよいです。

digdag run hello-world-workflow.dig 

すると以下のようになります。

2018-12-27 22:34:53 +0900: Digdag v0.9.31
2018-12-27 22:34:54 +0900 [WARN] (main): Using a new session time 2018-12-27T00:00:00+00:00.
2018-12-27 22:34:54 +0900 [INFO] (main): Using session /Users/keisukeyamashita/Dropbox/go/src/github.com/KeisukeYamashita/test-digdag/hello-world-workflow/.digdag/status/20181227T000000+0000.
2018-12-27 22:34:54 +0900 [INFO] (main): Starting a new session project id=1 workflow name=hello-world-workflow session_time=2018-12-27T00:00:00+00:00
2018-12-27 22:34:55 +0900 [INFO] (0018@[0:default]+hello-world-workflow+setup): echo>: start 2018-12-27T00:00:00+00:00
start 2018-12-27T00:00:00+00:00
2018-12-27 22:34:56 +0900 [INFO] (0018@[0:default]+hello-world-workflow+disp_current_date): echo>: 2018-12-27 00:00:00 +00:00
2018-12-27 00:00:00 +00:00
2018-12-27 22:34:56 +0900 [INFO] (0018@[0:default]+hello-world-workflow+repeat): for_each>: {order=[first, second, third], animal=[dog, cat]}
2018-12-27 22:34:56 +0900 [INFO] (0018@[0:default]+hello-world-workflow+repeat^sub+for-0=order=0=first&1=animal=0=dog): echo>: first dog
first dog
2018-12-27 22:34:56 +0900 [INFO] (0020@[0:default]+hello-world-workflow+repeat^sub+for-0=order=1=second&1=animal=0=dog): echo>: second dog
second dog
2018-12-27 22:34:56 +0900 [INFO] (0022@[0:default]+hello-world-workflow+repeat^sub+for-0=order=2=third&1=animal=0=dog): echo>: third dog
third dog
2018-12-27 22:34:56 +0900 [INFO] (0023@[0:default]+hello-world-workflow+repeat^sub+for-0=order=2=third&1=animal=1=cat): echo>: third cat
third cat
2018-12-27 22:34:56 +0900 [INFO] (0021@[0:default]+hello-world-workflow+repeat^sub+for-0=order=1=second&1=animal=1=cat): echo>: second cat
second cat
2018-12-27 22:34:56 +0900 [INFO] (0019@[0:default]+hello-world-workflow+repeat^sub+for-0=order=0=first&1=animal=1=cat): echo>: first cat
first cat
2018-12-27 22:34:57 +0900 [INFO] (0019@[0:default]+hello-world-workflow+teardown): echo>: finish 2018-12-27T00:00:00+00:00
finish 2018-12-27T00:00:00+00:00
Success. Task state is saved at /Users/keisukeyamashita/Dropbox/go/src/github.com/KeisukeYamashita/test-digdag/hello-world-workflow/.digdag/status/20181227T000000+0000 directory.
  * Use --session <daily | hourly | "yyyy-MM-dd[ HH:mm:ss]"> to not reuse the last session time.
  * Use --rerun, --start +NAME, or --goal +NAME argument to rerun skipped tasks.

Workflowの体系的な話

1. Workflowの定義

Workflowは.digのように指定されます。そしてファイル名があなたのワークフロー名になります。

トップレベルにtimezoneでどの時間帯かを指定します。デフォルトではUTCですが、Asia/Tokyoなどを指定することができます。

最初にdigdag initで初期化した時にできたワークフローの一行目です。

timezone: UTC

2. タスクの定義

タスクは+を使って定義し、上から下に実行されます。

3. オペレータを使う

タスクはオペレーターのタイプ名>のように書かれています。シェルスクリプトを実行したり、Pythonスクリプトを実行したり、メールを送ったり、いろんなことができます。

4. 変数を使う

すでにEmbedしている変数があります。

例えば以下のようなものです。

  • timezone
  • session_id
  • task_name

などです。詳しくは以下のリンクをご覧ください。

Workflow definition — Digdag 0.9.5 documentation

5. 計算をする

${}の中で基本的なJavascriptの計算はできます。また、時間の計算にはMoment.jsが使われています。

例えば一つのタスク内で以下のような計算ができます。

echo>: ${moment(session_time).format("YYYY-MM-DD HH:mm:ss Z")}

6. 変数を定義する

自分で変数を定義したいときがあるとしましょう。

三つの方法で変数を定義できます。

  • _exportで定義する
  • APIを使って定義する
  • Sessionを開始するときに定義する

Exportで定義するときは以下のようにします。

_export:
  foo: 1

+prepare:
  py>: tasks.MyWorkflow.prepare

APIを使う場合は以下の通りです。

class MyWorkflow(object):
  def prepare(self):
    digdag.env.store({"my_param": 2})

このようにdigdag.env.store(dict)で引数に辞書型を渡してあげます。

7. 他のdigファイルをimportする

以下のように他のファイルを!includeすることによってimportすることができます。

_export:
  mysql:
    !include : 'config/mysql.dig'
  hive:
    !include : 'config/hive.dig'

!include : 'tasks/foo.dig'

8. 並列処理

並列に処理をすることができます。方法としては、タスクに対して_parallel: trueとすることによってグループのタスクを並列処理できます。

例えば、以下のように定義します。

+prepare:
  _parallel: true

  +data1:
    sh>: tasks/prepare_data1.sh

  +data2:
    sh>: tasks/prepare_data2.sh

  +data3:
    sh>: tasks/prepare_data3.sh

+analyze:
    sh>: tasks/analyze_prepared_data_sets.sh

特定のタスクのみを並列処理したければ、_backgroud:trueと追記することによって定義することができます。

+prepare:
  +data1:
    sh>: tasks/prepare_data1.sh

  # +data1 and +data2 run in parallel.
  +data2:
    _background: true
    sh>: tasks/prepare_data2.sh

  +data3:
    sh>: tasks/prepare_data3.sh

9. 自動的に失敗したタスクのリトライ

_retry:Nというリトライパラメータが設定できます。このNというのは`1, 2, 3 ...です。

失敗してリトライできる回数を設定できます。

+prepare:
  # If +erase_table, +load_data, or +check_loaded_data fail, it retries from
  # +erase_table again.
  _retry: 3

  +erase_table:
    sh>: tasks/erase_table.sh

  +load_data:
    sh>: tasks/load_data.sh

  +check_loaded_data:
    sh>: tasks/check_loaded_data.sh

+analyze:
    sh>: tasks/analyze_prepared_data_sets.sh

公式ドキュメントにもあるように、失敗するとそのグループの最初のタスクから実行されます。

特定のタスクに_retry: Nを定義することもできます。

10. Error 通知

失敗すると以下のように_errorで定義したタスクを走られすことができます。

# this task runs when a workflow fails.
_error:
  sh>: tasks/runs_when_workflow_failed.sh

+analyze:
    sh>: tasks/analyze_prepared_data_sets.sh

11. スケジューリング

11.1 文法

ワークフローを定期的に行うには以下のようにschedule:で定義する必要があります。

timezone: UTC

schedule:
  daily>: 07:00:00

+step1:
  sh>: tasks/shell_sample.sh

どのように定義すうかは公式ドキュメントを参考にしてください。

もちろんcronのフォーマットでも指定をすることができます。

11.2 スケジューラーを実行する

digdag schedulerでコマンドを実行できます。

ファイルが変更していても、自動的にロードされます。

11.2 実行にかかった時間をアラートする

あるワークフローに、普段なら2分くらいしかかからないのに1時間などかかっていたら何かがおかしいことが想定できます。

そのようなために、timeとうものが指定できます。

timezone: UTC

schedule:
  daily>: 07:00:00

sla:
  # triggers this task at 02:00
  time: 02:00
  +notice:
    sh>: notice.sh

+long_running_job:
  sh>: long_running_job.sh
11.3 セッションのスキップ

例えば30分毎に実行されているワークフローがあり、普段は20分かかって終了するが、データ数が以上に多い祝日などは20分以上かかってしまうかもしれません。

そのようなときにskip_on_overtime: true | falseを設定することによって、複数のWorkflowが同時に実行されるのかを指定できます。

DigdagのGUIを使ってみる

Digdagには開発時につかうローカルモードと、運用時に使うサーバーモードがあります。

ローカルモードでは単一の.digで定義されたワークフローを実行できます。

f:id:bobchan1915:20181228044736p:plain

[分散ワークフローエンジン『Digdag』の実装 at Tokyo RubyKaigi #11]

またサーバーモードでは以下のようなアーキテクチャになっています。

f:id:bobchan1915:20181228044830p:plain

[分散ワークフローエンジン『Digdag』の実装 at Tokyo RubyKaigi #11]

まずは、実際にGUIを提供するサーバーを立ててみます。

digdag server --memory

そして、以下のようにワークフローをAPIを通して保存します。

digdag push hello-world-workflow

他のディレクトリにいるなら---projectで指定してください。

そしてhttp://localhost:65432にアクセスをします。

すると以下のようにワークフローがpushされています。

f:id:bobchan1915:20181228045031p:plain

そして選択してみると以下のようになっています。

f:id:bobchan1915:20181228045212p:plain

実際に実行しています。

するとセッションができます。

f:id:bobchan1915:20181228045437p:plain

StatusのSuccessボタンを指定すると、結果をみることができます。

f:id:bobchan1915:20181228045523p:plain

特にforeachなどが並列処理されていることがわかります。

ログレベルはPushのときに指定できます。

例えば

--log-level=info

といったような感じです。必要に応じて行ってください。

参考文献

www.slideshare.net

NATS on Kubernetesのいろは。メッセージセマンティックからPrometheus、Grafanaによるモニタリングまで

f:id:bobchan1915:20181224151947p:plain

本記事

本記事はKubernetes 3 Advent Calendar 2018の14日目の記事です。

本日(2018/12/26)の投稿になっているのは、空きがあったため埋めるために参加したからなのであって、決して遅刻などではありません!笑

モチベーション

私は学部3年生だった去年の2017年6月あたりにオンライン学習プラットフォームを一人で作っていました。ここでいうオンライン学習プラットフォームは、機械学習分野での「オンライン学習」を指します。

簡単にいうとニア・リアルタイムで機械学習エンジンのパラメータを更新していく、なんとも難しいシステムです。当初は、単線的にニューラルネットワークでやろうと思っていましたが、そのアルゴリズム(誤差逆伝搬あたり)ゆえに、分散的に処理を実行するのは不可能でした。そのときはApache Hadoop、Apache Kafka, Apache Cassandraなどを主に使っていましたが、何より一人で構築するのは大変でした。

f:id:bobchan1915:20181226033724p:plain

ここでApache Kafkaという分散メッセージングシステムが出てきたわけですが、このときにメッセージングセマンティックスだったり考えることが多いなと思いました。ありとあらゆるメッセージングシステムがある今の時代に、知識なしでは選定するのは難しいなとその時は思いました。

たとえばApache Samza、Apache Pulsar(私の一番好きなもの)、Apache Beam、Apache Flinkなどなどです。主にメッセージングセマンティックは

  • at-least-once
  • at-most-once
  • exactly-once

とあるわけです。ここで「主に」とつけたのは、Apache Pulsarをはじめとして「工夫してくる」セマンティックが登場してきているからです。Apache PulsarでいうとEffectively-once(効率的に一つ)です。

短絡的にこれで解決じゃないか!と思うかもしれません。しかし、メッセージングセマンティックだけでなくコミュニティの成熟度をはじめとしてAPIのサポート状態、運用の難しさ、障害点の有無など、差異が多少なりとも存在するので、設計要件にあった技術選定ができるかどうかは一概に言えません。

少し話が変わりますが、私がいま専攻している工学という学問でも進学時に受けたガイダンスでは

工学は、判断を下すために客観的資料を揃え、決定をする総合性をもつ科学技術である。...。このような経験を通じて、工学は社会における工業のあり方、工学の意義、役割を改めて問い直し、一層、総合的な視野、判断をもつ科学として脱皮しつづけている。 工学は、人間が道具をつくり始めた技術の起源と共に長い歴史をもち、同時に絶えず脱皮、発展をつづける若い体質をもっていると言えよう。

と書かれてありました。やはり、工学(英語でエンジニアリング)を実践する人が技師(エンジニア)であり、総合的な問題解決手段の術を知ることがより良いエンジニアリングになれるのではないかと思っています。

その一環として、Cloud Native Computing FoundationのIncubator ProjectであるNATSを使ってみて、自分の知識として消化することを目指しています。

今までまとめた関連する備忘録的な記事は以下の通りです。

続きを読む

Concourseで継続的デリバリー。そしてSpinnakerとの比較

f:id:bobchan1915:20181223164839p:plain

本記事

本記事はConcourse Advent Calendarの23日目の記事になっています。

もうすぐ学部を卒業するので、積極的にアウトプットしようと思って、以下のAdvent Calendarも参加したので、もし興味がございましたらご覧ください。

Vue.js Advent Calendar 2018

www.1915keke.com

CircleCI Advent Calendar 2018

www.1915keke.com

Kubernetes Advent Calendar 2018

www.1915keke.com

オフィスや自宅を快適にするIoT byゆめみ③ Advent Calendar 2018

www.1915keke.com

動機

本記事を書こうと思ったのは、Concourseのバージョンアップに伴い、実際に動作させることができるチュートリアルやリファレンスがあまりにも少ないし、日本語ならなおさら少ないと思ったからです。

私はDevOpsやCloud Nativeなどを熱く注目していて、新しいデプロイメントパターンやアーキテクチャを考案し、これから働くであろう組織に最大の恩恵を与えられるようなエンジニアになりたいと思っています。

例えば、宣言的継続的デリバリーをSpinnakerで実現する方法を過去に提案しました。

www.1915keke.com

このような提案も他のエンジニアの知見をまとめたブログや書籍がなければ思いつくことはできなかったでしょう。仮にドキュメントがなかったりすると、ソースコードを読んだり、直接開発者に連絡してみたりしなければならず、全世界がそのように時間を消費していたらもったいないです。

この記事によって現時点でのConcourseの解説を明文化することにより、他の誰かがより簡単にConcourseを使って新しい価値を生んでもらえれば執筆者としては嬉しい限りです。

続きを読む

Siderでコードレビューを自動化してプロジェクトのエントロピーを維持する

f:id:bobchan1915:20181219233948p:plain

本記事

本記事では自動コードレビューができるSider(旧SideCI)を使ってみようかなとおもいます。

よくミスタイプとかして、それを修正するプルリクが必要になったりするとプロジェクトのエントロピーが圧倒的に増大するので防ぐためにも導入してみます。

インストール手順

STEP1: 許可するリポジトリを選択する

まず、最初に以下のような画面になります。

f:id:bobchan1915:20181219222945p:plain

ここで「Add a new organization」を選んでリポジトリを追加しましょう。

続きを読む

Raspberry PiとImgurを使って無料で自宅監視カメラLINEボットを構築する

f:id:bobchan1915:20181217053625p:plain

本記事

本記事では、実際にRaspberry Piのカメラモジュールを使って監視カメラサービスを構築してみようと思います。

完成形は以下のようにかまると呼びかけると家の画像を返信してくれるものです。すべて無料の制限内にします。

f:id:bobchan1915:20181217073525j:plain

モチベーションとしてはカメラモジュールの使い方などを解説している記事は多くありますが、実際にCloud Nativeな技術と組み合わせて解説し、運用しているものがないと思ったからです。

使うもの、環境は以下のようです。

Raspberry Pi Model B

Raspberry Pi 3 Model B V1.2 (日本製) 国内正規代理店品

Raspberry Pi 3 Model B V1.2 (日本製) 国内正規代理店品

続きを読む

Argo CDによってGKEでGitOpsをする

f:id:bobchan1915:20181206151759p:plain

はじめに

最近読んだ鎌倉時代の歌人、鴨長明の『方丈記』にも

ゆく河の流れは絶えずして、しかももとの水にあらず。

とありますが、私たちのソフトウェアも然りです。

毎日更新され、デプロイされ、時に不可逆に破壊され。そして、ちぐはぐな形に落ち着くまで絶えず変更されているように感じます。

そのようなことにならないためにもOpsやCDについて注目しています。

本記事

本記事はKubernetes Advent Calendarの15日目の記事になっています。

どうも、私はもうすぐ大学を卒業(予定)の@timtimtim1026です。

コメントや間違いなどがあればDMやリプを軽く飛ばしてもらえると嬉しいです。

今回は、GitOpsを実現するためのツールとしてArgo CDが注目を集めているので、GitOpsについて考えていこうと思っています。

また今回はたまたまArgo CDを使ってみますが、だいたいのGitOpsに導入しやすいソフトウェアは、似たような構成なので、体系的に学べる記事にできれば嬉しいと思っています。他にもWeave FluxやJenkins Xなどがありますが、それにも通用する知識をつけられれば何よりです。

コンテンツ

本記事の目次は以下の通りです。

興味がある項目だけでも、ぜひ読んでみてください。

  • はじめに
  • 本記事
  • コンテンツ
  • GitOpsについて
    • GitOpsの定義
    • Cloud Nativeと継続的デリバリー
    • 構成
  • Argoについて
    • まずArgoとは
    • Argo CDとは
    • 構成アーキテクチャ
      • 1. GitOpsを実現する
      • 2. CIと接続
      • 3. CDとしてDeployする
  • 準備
    • GCPにCLIからログインする
    • Projectを作成して設定
    • テストクラスタを作成
    • Credentialを取得
  • Argo CDをインストール、基本を理解する
    • ClusterRoleBindingを作る
    • Namespace作成してArgo CDを入れる
    • Argo CD CLIをインストールします
    • Argo CD API サーバーにアクセス
    • WebUIからGithub Hookの設定をする
    • アプリケーションを設定する
    • 同期する
    • 実際にGitOpsになっているかを確認
  • 機能のDeep dive
    • リアルタイム同期のためのWebhook
    • Application(リポジトリ)をまとめるためのProject機能
    • APIドキュメントをみる
    • Hookを設定する
    • argocdコマンド一覧
  • まとめ
  • 参考文献
    • Argo公式ドキュメント
    • Japan Container Daysであった発表
    • KubeCon North America 2018での発表 
続きを読む

CircleCIでSpinnakerのデプロイメントパイプラインをデプロイする

f:id:bobchan1915:20181206211505p:plain

どうも、もうすぐ大学卒業の@timtimtim1026です。

もしコメントなどがございましたらDMなり、リプライしてください。

本記事はCircleCI Advent Calendarの14日目の記事になっています。

本記事

この記事では、CircleCIを使ってSpinnakerのデプロイメントパイプラインをデプロイする方法を解説します。

twitter.com

今回の目的としては、CircleCIを使いながら継続的デリバリー(以下、CD)を構築する一例を知ってもらうことです。また、そのなかで紹介するCircleCIの知識が何かしら役に立てられればいいなと思います

考え方としては、今回使うCircleCIやSpinnakerに限らずあらゆるCDにも、CIにも言えることなのでSpinnakerだけに限った話ではありません。

続きを読む

Terraformで運用しているLineBot家計簿をGCPで使う

f:id:bobchan1915:20181210104636p:plain

はじめに

私は自分で作ったLineBotを使って家計簿をつけています。

クラウドにはGoogle Cloud Platform(GCP)の無料枠を使っていて、データベースにはCloud SQL(MySQL)を使っています。

自分でデータを集めているので、以前にもApache Supersetなどを用いてデータ分析をしていました。

www.1915keke.com

しかしながら、無料枠を使っていく中で、無料枠が終わって、別の保有しているアカウントに移行したい時に**まったく構成管理が宣言的にできていないことに気づいて、今回はTerraformを使ってやっていこうと思います。

続きを読む