2024-12-24

Zapier×Googleフォームで労務相談プライベートチャンネル作成を自動化してみた

この記事でわかること

労務相談用のSlackプライベートチャンネル作成自動化をノーコードでやる。
- この記事の対応で roumu-<<問い合わせ社員のメールアドレスホスト部>>-<<実行日時>> といったチャンネル名のものが自動生成される。
実装方法はZapierとGoogleフォーム(＋労務メンバー管理でスプレッドシート)を利用。

経緯

現職の労務の方からこんな記事のようなことやりたい〜！と相談されたことがきっかけ。
上記記事だとショートカットコマンドを使っているが、コードで実装が面倒だったのでノーコードでなんとかできんかなという思いから、試してみることに。

この構成のメリット

ノーコードなので労務側でもメンテ可能。
労務メンバーの改廃はスプレッドシートで管理しているのでメンテが楽ちん。

事前準備

Googleフォームの準備(クリックすると詳細が展開されます)
①下記のようなフォームを作成する。
- ②回答の メールアドレスを収集する を 確認済にする
メンバー管理用のスプレッドシートの準備。(クリックすると詳細が展開されます。)
①下記のように労務メンバー一覧のメールアドレスを入力する。

Zapier実装(全体像)

Zapier実装(詳細)

※詳細は各項目をクリックすると展開されるようにしています。

フォーム入力がトリガー(New Form Response in Google Forms)
事前準備で用意したGoogleフォームを指定します。
フォーム入力者のSlackIDを取得する(Find User by Email in Slack)
Find user by Email でフォーム送信したユーザーのメールアドレスをSlack IDに変換します。(そうしないと招待処理できないので)
フォーム実行日時を取得する(Date / Time in Formatter by Zapier)
念の為の対応として、プライベートチャンネルの末尾に フォーム送信日時 を付与したいので、そのための対応

Formatter by Zapier で現在の実行日時を取得。

→ フォーム実行日時を付与しておくことで、同一人物からの別の労務相談チャンネルが作成できるようにするため。

ポイント1: inputには {{zap_meta_human_now}} という変数(現在の実行日時を示す変数) を入れておく。

ポイント2: To Timezoneには Asia/Tokyo を、From Timezoneには UTC を入れておく。こうしておかないとアメリカ時間になっちゃう。
メールアドレスの@より前を抽出(Text in Formatter by Zapier)
チャンネル名に、フォーム送信者のメアド部分を用いるのがわかりやすいと思ったので、フォームからフォーム送信者のメアドを取得する

ポイント1: Separator に @ と指定することで、ホスト部とドメイン部を分割。

ポイント2: Segment Index に First と指定することで分割した際の前半部分だけを取得するようにしている。
メールアドレスのドットをハイフンに変換(Text in Formatter by Zapier)
Slackチャンネル名にはドットが使えないのでドット部分をハイフンに変換。
プライベートチャンネルを作成する(Create Private Channel in Slack)
プライベートチャンネル作成処理

roumu- のあとに、3. フォーム実行日時を取得する と メールアドレスのドットをハイフンに変換 の結果を指定して連結します。
フォーム入力者を作成したプライベートチャンネルに招待する(Invite User to Channel in Slack)
Channel に 6. プライベートチャンネルを作成する の Result Channel Id を指定し、 Users に 2. フォーム入力者のSlackIDを取得する で得られた ID を指定します。

注意点： ChannelとUsersにはデフォルトでは入力できない模様なので、横にあるハンバーガーメニューから"Custom"というのを選択すると入力できるようになります。
スプレッドシートから労務メンバーのメールアドレス一覧を取得する(Get Many Spreadsheet Rows (Advanced) in Google Sheets)
労務メンバーの招待処理①

事前準備で用意したスプレッドシートを指定します。

ポイント1: Columns にはメールアドレスが書いている列を指定してください。例：A列に入力しているなら A:A
スプレッドシートの内容をループ処理(Create Loop From Line Items in Looping by Zapier)
労務メンバーの招待処理②

労務メンバー全員を招待できるように、 Looping by Zapier を利用してループ処理。

8. スプレッドシートから労務メンバーのメールアドレス一覧を取得する の実行結果の Formatted Rows COL A: を指定する。Values to Loop はわかりやすくするために、 email という変数名にしておく。
メールアドレスからSlackIDに変換(Find User by Email in Slack)
労務メンバーの招待処理③

2. フォーム入力者のSlackIDを取得する と同様にスプレッドシートに入力されているメールアドレスをSlack IDに変換する。

Email に指定するのは 9. スプレッドシートの内容をループ処理 の結果の Email 変数を指定する。
作成したプライベートチャンネルに招待(Invite User to Channel in Slack)
労務メンバーの招待処理④

7. フォーム入力者を作成したプライベートチャンネルに招待する と同様に、労務メンバーもチャンネル招待する。

Users に指定するのは 10. メールアドレスからSlackIDに変換 の実行結果の ID を指定すること。

2024-04-26

Zapierで日付加工処理をある程度柔軟にしてNotionの繰り返し予定の件名を更新する

この記事は？

下記悩みを解決した記事です。

NotionのDatabaseの繰り返し予定は便利だけど、件名にYYYYMMDD形式といった内容を入れられない。
ZapierでNotionページを作ると件名は柔軟に使えるが、Notionのテンプレートが使えない。

両方のいいとこどりをしたいのにーーーー！となったので考えました。上記を短絡的に解決しようとするとAWS Lambda とか GASで頑張りたくなるのですがそうしないための記事です。

Notion手順

Notion DBで繰り返し予定を作成する。
- これは任意で好きなテンプレートを使って良いです。件名も適当でいいです。
これだけです。ここはNotionの通常機能なので詳細は https://www.notion.so/ja-jp/releases/2022-11-08 を参照ください。

Zapier手順

Zapierで下記のような感じでAutomationを組む。全体像は↓です。

Trigger
- New Database Item で指定のDatabaseが作られたら発火するようにします。
時間計算処理
- {{zap_meta_timestamp}} という変数？を使うとZap実行時間のUNIX時間が取得できるのでこれを利用します。
  - 私は定例資料を前日に作りたかったので、翌日を表すにはこのUNIX時間に 86400秒(1日) を設定しました。
フォーマットを変換
- UNIX時間だと人間の目で見ると、ナンノコッチャなので、YYYYMMDD形式に直します。
Notionページの件名を修正

以上です！私はついでに、Slack通知もNotionでやってもらうことにしました。

ちょっと怖いところ

Step4で「あんたループしてますよ」とエラー表示されている。
そんなことないと思うんだけどな。。

参考にさせていただいた記事(感謝)

https://help.zapier.com/hc/en-us/articles/8496275717261-Insert-the-time-your-Zap-runs-into-a-field#h_01HJ1D5RZTSWA5DD5F4JHSJYYG

goodpatch-tech.hatenablog.com

hajimarinomachi.com

2023-11-29

社内ブログに投稿しました

ヘルプデスク業務を楽にするためにSlackとGitHub Projectsを同期するヘルプデスクツールを自作したtech.mntsq.co.jp という記事を投稿しました。

こんなこと書いてます。

ヘルプデスク業務を楽にするためのツールを作成した話。
GitHub ProjectのItemとSlackを双方向同期したり、Azure OpenAI等を利用して効率化したりしてます。

hot entryにもなりました(嬉しい)https://x.com/hatebu/status/1727877377370489186?s=20

2023-03-17

SlackのEnterprise GridでAdmin APIを使えるようにするまで

この記事は？

Slack Enterprise Gridプランで使えるAdmin系のAPIで利用するためのTokenを入手するまでの手順。
- 公式の手順には利用するための手順が会たるが、 うん。よくわからん。 となったので試行錯誤して分かったことをまとめます。
- 通常のSlack AppのようにTokenを入手しようとすると下記のような画面になってしまう。
  - どうやら、Admin APIは通常のTokenとは違う方法で発行しなければいけないらしい？と分かり、それをまとめた形です。
「色々試してうまくいった」という感じなのでお作法やら何やらが間違っている可能性あり。

参考にさせていただいたURL

github.com

この手順書の最終ゴール

作成されたTokenを使って admin.teams.lis のテスターページから、管理化にあるSlackワークスペースの一覧が表示できるようになること。

前提条件

作業環境はMacを想定しています。 ※Windowsの方は適宜、読み替えてください。
Node.JSが動く環境を想定しています。
- Node.JS インストール とうでググれば環境構築手順は多数出てくるので、この資料では環境構築については省きます。

手順概要

[Slack] 適当なSlack Appを作る。
- アプリ作成時の初期画面で、 From an app manifest を選択して、下記JSONを指定してください。
- 権限として、"admin.teams:read" を利用することにしているので権限を変えたければ、アプリ作成後に OAuth & Permissions のメニューから必要な権限を選択してください。
- インストール先のSlackワークスペースはどこでもいいです。
- ```
{
    "display_information": {
        "name": "admin_teams_read"
    },
    "oauth_config": {
        "redirect_urls": [
            "https://localhost:3000"
        ],
        "scopes": {
            "user": [
                "admin.teams:read"
            ]
        }
    },
    "settings": {
        "org_deploy_enabled": false,
        "socket_mode_enabled": false,
        "token_rotation_enabled": false
    }
}
```
作成された画面のApp Credentialsという項目に、Client IDとClient Secretの項目があるので、それぞれメモしておく。(※あとで使う)
[Slack] Manage Distribution メニューを選択して、Remove Hard Coded Information の欄にチェックを入れて、 Activate Public Distribution を選択する。
[Slack] 同画面の上部に Shareble URL という項目があるので、それに記載してあるURLをメモしておく。(※あとで使う)

[PC] OAuth2サーバ用の自己証明書を作成する。

すぐに利用しなくなる証明書なので /tmp 配下に作成しておく。

mkdir -p /tmp/slack-oauth2.0-client

cd /tmp/slack-oauth2.0-client

openssl genrsa 2048 > server.key

#※証明書について色々聞かれるが「Locality Name」だけ「JP」と答えて、あとは未入力。
openssl req -new -key server.key > server.csr
  # You are about to be asked to enter information that will be incorporated
  # into your certificate request.
  # What you are about to enter is what is called a Distinguished Name or a DN.
  # There are quite a few fields but you can leave some blank
  # For some fields there will be a default value,
  # If you enter '.', the field will be left blank.
  # -----
  # Country Name (2 letter code) []:JP <-ここだけJPにする
  # State or Province Name (full name) []:
  # Locality Name (eg, city) []:
  # Organization Name (eg, company) []:
  # Organizational Unit Name (eg, section) []:
  # Common Name (eg, fully qualified host name) []:
  # Email Address []:
  # 
  # Please enter the following 'extra' attributes
  # to be sent with your certificate request
  # A challenge password []:

 openssl x509 -days 3650 -req -sha256 -signkey server.key < server.csr > server.crt

[PC]作業ディレクトリを作成し、そこにOAuth2サーバー用のスクリプトを配置する。

配置するのは下記のapp.jsとpackage.jsonです。

app.js

const request = require('request');
const express = require('express');
const app = express();
const fs = require("fs");

const slack_client_id = process.env.SLACK_CLIENT_ID;
const slack_client_secret = process.env.SLACK_CLIENT_SECRET;

app.get('/', (req, res) => {
    // 認可コードの取得
    const code = req.query["code"];

    // 認可コードを使って、アクセストークンをリクエストする
    request({
        url: "https://slack.com/api/oauth.v2.access",
        method: "POST",
        form: {
            client_id: slack_client_id,
            client_secret: slack_client_secret,
            code: code,
            redirect_uri: "https://localhost:3000/"
        }
    }, (error, response, body) => {
        // レスポンスからアクセストークンを取得する
        const param = JSON.parse(body);
        console.log(param);
        const access_token = param['access_token']; // アクセストークン
    })
})

// http サーバ
var http = require("http").Server(app);         // http サーバを立てる
http.listen(80);                                // 80番ポートで待つ

var opt = {                                     // SSL 認証のパラメータ
  key:  fs.readFileSync("/tmp/slack-oauth2.0-client/server.key"),          // 秘密鍵
  cert: fs.readFileSync("/tmp/slack-oauth2.0-client/server.crt"),          // 証明書
  //passphrase: "password",                     // パスワードを設定した場合
};
var https = require("https").Server(opt, app);  // https サーバを立てる

https.listen(3000, () =>{
        console.log('HTTP Server(3000) is running.');
});

package.json

{
  "dependencies": {
    "cors": "^2.8.5",
    "express": "^4.17.0",
    "request": "^2.88.0"
  }
}

[PC]npm install コマンドで初期化しておく。
[PC]手順2でメモしておいた Client IDとClient Secretを下記のように一時的に環境変数に入れておく。
- ```
export SLACK_CLIENT_ID="メモしたClient ID"
export SLACK_CLIENT_SECRET="メモしたClient Secret"
```
node app.js でOAuth2サーバを起動して待ち受けておく。
[PC] 手順4でメモしたShareble URLの末尾に&redirect_uri=https://localhost:3000/ とつけたURLを適当なブラウザで開く。
[PC] Slackの認証画面が表示され、画面右上の方にSlackワークスペースを選択する画面が表示されるので、オーガナイゼーションのSlackワークスペース(一番親のワークスペース)を選択して、 Allow ボタンを選択。
[PC]手順9で立ち上げていたOAuth2サーバのコンソールに access_token という値があるのでそれが今回の目的のSlack Tokenなので、それをメモしておく。
- 手順11でアクセスしたSlackの画面はグルグルとロード画面のままになっているが☓ボタンで閉じてOK。
以上

試してみる

admin.teams.list のテスター画面にて取得したTokenを指定してみる。
- 意図した結果になればOK。

2023-02-24

情シス向けのローカル環境でのTerraformテスト環境構築方法

この記事について

社内の情シスメンバー向けに勉強会的なものをやったときにステップバイステップで環境構築できるように説明した資料。
- ※SREなどガチガチのインフラ屋さんなどには情報量が薄いので、この記事の内容は適しませんので、このページはそっ閉じしてください。
- 勉強会時には記述していたが、ブログ記載にあたり記述内容を削除、修正しているところがあります。故に、一部説明が不十分な箇所があります。
  - 特に肝心な認証周りの記述については、記載内容薄めです。
    - 社内勉強用には認証周りの記述もしていたのですが、さすがに機微な情報なので...。
既に社内でTerraform環境によるデプロイができている状態の人向け。
- 他の人がTerraformによるCI/CD環境構築してくれているが、「管理者が自分に変わってしまった！」等で、サクッと自分のPC(Macを想定)でTerraformの挙動を試してみたい方向け。
お題として、「AzureAD環境にあるユーザーを操作する」みたいな感じで書いてますが、適宜ご自身の会社の環境に読み替えてください。
- 余談：AzureADをTerraform管理下に置くためのファーストステップには以前にそんな感じの記事を書いたのでそちらを参照ください。 ※記事の内容が古いのでいずれ直します。。
  - Azure環境のTerraform管理をはじめる

最終形

下記のようなことができるようになること。

terraformコマンドの基本的なものが理解できる。
ローカルPCにてTerraformのインストール＆バージョン切り替えができる。
terraform planでtfファイルと実環境の差分を見れること。
特定リソース(今回はダミーのAzureADユーザーを作成)をimportできること。
やらかしてしまった ときのterraform stateの修正方法。

実践編1: terraformコマンドの基本を理解

情シス的に下記を知っていればだいたいは対処できる系のコマンド(多分)

terraform init
- terraformコマンドを叩くための初期化コマンド
  - これを実行すると各種providerなど必要なものをダウンロードして実行環境整えてくれる
terraform plan
- 現行のtfファイルと相手先の環境が合っているかの確認コマンド
terraform apply
- 現行のtfファイルの内容で相手先環境を更新
terraform import
- 相手先リソースの内容をstateファイルに書き込む
terraform state pull > 出力先ファイルパス.json
- 現行の構成状態(stateファイル)を取得 ※テキストに出力したい場合は > とかで外部出力する。
  - ※出力したファイルを別のフォルダとかにコピーしておくと更に安全。
  - バックアップファイル自体を削除したり、改変しちゃったときに別場所にコピーしたものからも復旧できるので。(バックアップはいくつあってもいい)
terraform state -force push
- ローカルにあるstateファイルの内容で更新。
  - forceつけとかないと大概の場合うまくいかない。
  - これを実施するときは最終手段。(何かしらのリカバリ系)
地味に使う技：コマンドに -var "変数名=値"
- tfファイルに環境ごとで違う変数をわたしたいときに使う
  - 例: -var “env=prod” とするとenvという変数にprodを入れた状態でTerraformを実行できる。

実践編2: terraformをローカルPCにインストールする。

Terraformはバージョンを変えることが割とあります。
- バージョンが違うとtfファイルの書き方が変わるなど
そのため、Terraformのバージョン変更や変更が容易な tfenv を用います。
手順
1. ターミナルで brew install tfenv コマンドでtfenvをインストール。
2. パスを通すために、一旦ターミナルを終了、再度起動。
3. tfenv --version でバージョンが表示されることを確認。
4. ご自身のプロジェクトで何のTerraformバージョンが使われているか調べるために terraform { と言ったキーワードで検索。
  - required_version = "1.2.5" みたいになっていれば、それがそのプロジェクトのバージョンです。
  - まぁ確認しなくても、違うバージョン使うと このバージョン使ってね！ というエラーが出て、怒られるのでこんなことしなくても大丈夫そう…
5. tfenv install <<バージョン>> で指定されたTerraformのバージョンをインストールしつつ、 tfenv use <<バージョン>> で利用するTerraformバージョンを指定する。
6. terraform --version で指定されたバージョンがインストールされたことを確認。

実践編3: terraform planでtfファイルと実環境の差分を見れること。

※下記は環境により異なるので一例。

各環境に合わせた認証情報をターミナル上でセットする。
- 例：
  - AzureAD環境の場合
    - この記事の「TerraformでAzureリソースを作成してみる」などを参考に、相手先AzureADのサブスクリプションIDやテナントID等を環境変数に指定しておく。
  - AWS環境の場合
    - aws configureコマンドなどで、対象のAWSアカウントの認証情報をセットする。

応用編1: AzureADの特定リソース(今回はAzureADユーザー)をimportする

AzureADで適当なユーザーを作成。
そのユーザーのページを開いて、 オブジェクト ID をメモする。
作業ミス時リカバリ対応のため現状のstateファイルのバックアップを取得しておく。
- terraform state pull > statefile_backup.txt
importする。今回使うリソースは azuread_user。
1. リンク先の末尾に import文の例がある。
  1. 今回だと terraform import azuread_user.my_user 00000000-0000-0000-0000-000000000000
    1. my_user の部分がtfファイルに記載した名前。 000000〜 の部分にオブジェクトIDを指定する。
user-test.tf と言った形の拡張子.tf の適当なテキストファイルを用意し、下記のように作成する。
jsx resource "azuread_user" "my_user" {
試しに terraform plan してみる。
1. 差分が表示されるので、差分がなくなるように作成したtfファイル(上記例だとuser-test.tf)を追記、修正する。

応用編2: やらかしてしまったときのterraform stateの修正方法。

※上記の 応用編1 の変更内容を「やらかしてしまった」と仮定して、応用編1の変更内容をなかったことにします。
(この操作によりリカバリ操作の雰囲気がつかめるはず)

応用編1 で取得したバックアップファイルの statefile_backup.txt を使います。
terraform state push -force statefile_backup.txt を実行。
- これをすることで応用編1 の変更内容の前の状態に戻せる。
terraform plan -var "env=prod" を実行。
- 応用編1 と違い、新規リソースが作成しようとする挙動になることを確認。

2023-02-23

GCPのCloud Run環境にデプロイするまでの手順( + Node.js環境の構築 )

この記事について

社内向けに勉強会的なものをやったときにステップバイステップで環境構築できるように説明した資料。
Cloud Runで何かしらのbotを作成したいが何していいかわからない、という情シス向けの資料
Cloud Runにデプロイする環境はNode.jsのものを利用するので、Node.js環境の構築から触れてます。

免責

GCP環境及び GCPプロジェクトは事前に用意しておいてください。
- GCP環境の開設等はググればたくさん情報があるので、そちらでお願いします。
想定端末はMacです。( Windows環境では若干違う情報もあると思います )
コードが綺麗とかは度外視してます。
- 私自信はガチガチの開発者じゃないのでそういうのはできない。
セキュリティ周りのことも何も考慮していないので実際に運用する場合は自己責任でお願いします。
- たとえばAPI TokenはSecret Managerを使ってそこに保存するようにする、とか。
- たとえばheaderとかに任意の文字列とかを設定しておいて、その文字列と一緒じゃないとリクエストを受け付けないようにする、とか。

参考にさせていただいたURL

github.com

qiita.com

https://cloud.google.com/run/docs/quickstarts/build-and-deploy/deploy-nodejs-service?hl=ja

実施するステップ

Node.js環境の構築。
構築したNode.js環境で、hello, world を出力できるようになることを確認。
Cloud Runにデプロイする予定のローカルWebサーバーを構築。リクエストを投げて hello, world と返却されることを確認。
Cloud Runに上記環境をデプロイ。デプロイした環境(Internet上の環境) で hello, world と表示されることを確認。

実践編1: Node.js環境の構築

正直、構築できれば何でもいいですが利便性観点でNode.jsのパッケージが選択可能なnvmを使って環境構築します。

nvmのインストール
1. curl -o- [https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh](https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh) | bash を実行。
2. ターミナルを閉じて、再度開いて nvm -v コマンドでnvmバージョンが表示されればOK
Node.jsのインストール ( 2023年2月時点でのLTS版である18.14.1をインストールする手順 )
1. nvm install v18.14.1
  - LTS版を入れたい場合は単純に nvm install --lts でもOKですが勉強のために、あえてバージョン指定にしています。
2. 普段使う、Nodeバージョンを指定する。
  1. nvm use v18.14.1
3. node --version と打って、想定のNodeバージョンかを確認する。
hello, worldしてみる。
1. node と打ってnode CLIを起動。
2. console.log("hello, world"); と打ってhello, worldが出ればOK。

実践編2: コンテナ想定環境のテスト

適当なフォルダを用意し、下記2つのファイルを用意する。

index.js

 /*--------------------------------------------------
 Expressサーバ起動用に必要な記述
 --------------------------------------------------*/
 const express    = require('express');
 const bodyParser = require('body-parser');
 let app = express();
 app.use(bodyParser.urlencoded({ extended: true }));
 app.use(bodyParser.json({
   verify: (req, res, buf) => {
     req.rawBody = buf;
   }
 }));
 const port = process.env.PORT || 8080;
 app.listen(port);
 console.log('listen on port ' + port);

 app.post('/', async function(request, response){
   /*--------------------------------------------------
   実処理(ここ以降に実際に処理したい内容とかを書く)
   --------------------------------------------------*/
   console.log("headers", JSON.stringify(request.headers));
   console.log("body", JSON.stringify(request.body));
   console.log("hello, world");

   response.json("ok");
   return;
 });

npm init で package.json を生成する。
1. 質問は全部デフォルトのものを答える。
npm install express でexpressをインストールする。
npm install node-fetch-commonjs でnode-fetch-commonjsもインストールしておく。
node index.js を実行してExpressサーバ(Webサーバ)をlocalhostで起動する。

別のターミナルでnodeと実行し、node CLIから下記コマンドを実行して、上記の手順5のターミナルでhello, worldが返却されることを確認。

 const fetch = require('node-fetch-commonjs');

 const headers = {
   "content-type": "application/json",
 };

 const body = {
   "body": "dummy"
 };

 fetch('http://localhost:8080', {
   method: 'POST',
   headers: {
     'Content-Type': headers["content-type"],
   },
   body: JSON.stringify(body)
 });

実践編3: Cloud Runにデプロイ

デプロイ対象のGCPプロジェクトで、このページなどを参考に、 Cloud Build と Cloud RunのAPIを有効化する。

実践編2で用意したフォルダに下記ファイルを用意する。

Dockerfile

 FROM node:18.14-slim
 WORKDIR /usr/src/app
 COPY package*.json ./
 RUN npm install --only=production
 COPY . ./
 CMD [ "npm", "start" ]

実践編2で用意した package.json に下記を追記する。

scripts に "start": "node index.js", を追記。

 //これを
 "scripts": {
   "test": "echo \"Error: no test specified\" && exit 1"
 },
 //こんな感じ
 "scripts": {
   "start": "node index.js",
   "test": "echo \"Error: no test specified\" && exit 1"
 },

gcloud CLI をインストール。
gcloud auth login --no-launch-browser で認証情報をセットする。
1. URLが表示されるので認証するユーザーで認証後、表示された Enter authorization をターミナルに貼り付け。

下記コマンドで環境情報諸々をセットしておく。

 gcloud config set run/platform managed
 gcloud config set run/region asia-northeast1
 PROJECT_ID="事前に用意したGCPプロジェクトの名前"
 image_name="CloudRun上に表示する名前"

下記コマンドでデプロイする。

※下記コマンド実施後、デプロイされたCloud Run環境のものが表示されるのでメモしておく。

 #Container Registryにアップ
 gcloud builds submit --project ${PROJECT_ID} --tag gcr.io/${PROJECT_ID}/${image_name}
 #上記内容をCloud Runにデプロイ    
 gcloud beta run deploy --project ${PROJECT_ID} --image gcr.io/${PROJECT_ID}/${image_name} --platform managed

念の為、 gcloud auth revoke で認証情報を破棄しておく。

別のターミナルでnodeと実行し、node CLIから下記コマンドを実行。

 const url = "デプロイ時に表示されたURL";
 const fetch = require('node-fetch-commonjs');

 const headers = {
   "content-type": "application/json",
 };

 const body = {
   "body": "dummy"
 };

 const hoge = fetch(url, {
   method: 'POST',
   headers: {
     'Content-Type': headers["content-type"],
   },
   body: JSON.stringify(body)
 });

Cloud Runにアクセスして、デプロイした名前の環境を開きログを確認。hello, worldが記載されていることを確認。

2022-05-16

Zapier × Slack × asanaでタスク管理とユーザーコミュニケーションを効率化する

ノーコード

書いた。

[ノーコード] Zapier × Slack × asanaでタスク管理とユーザーコミュニケーションを効率化する moneyforward.com

この記事でわかること

経緯

この構成のメリット

事前準備

Zapier実装(全体像)

Zapier実装(詳細)

この記事は？

Notion手順

Zapier手順

ちょっと怖いところ

参考にさせていただいた記事(感謝)

この記事は？

参考にさせていただいたURL

この手順書の最終ゴール

前提条件

手順概要

試してみる

この記事について

最終形

実践編1: terraformコマンドの基本を理解

実践編2: terraformをローカルPCにインストールする。

実践編3: terraform planでtfファイルと実環境の差分を見れること。

応用編1: AzureADの特定リソース(今回はAzureADユーザー)をimportする

応用編2: やらかしてしまった ときのterraform stateの修正方法。

この記事について

免責

参考にさせていただいたURL

実施するステップ

実践編1: Node.js環境の構築

実践編2: コンテナ想定環境のテスト

実践編3: Cloud Runにデプロイ

応用編2: やらかしてしまったときのterraform stateの修正方法。