[Slack] チャンネル ID を確認する方法

すごく詰まらない内容ですが、ググっても一番分かりやすい方法を示しているところが見当たらなかったので備忘録的に残しておきます。

Slack は ワークスペース > チャンネル といった構成になっており（恐らく）、エンジニアをやっていると、この「チャンネルの ID」を知りたくなるときが、まあまああります。

このチャンネル ID を知る方法はいくつかやり方があります。

  1. 当該チャンネルの詳細情報モーダルウィンドウから確認する
  2. Slack ワークスペース内のチャンネルメニューから当該チャンネルのコンテキストメニューでコピー＆ペーストして確認する
  3. Slack を Web ブラウザーで利用しているときの URL から確認する
  4. Slack API を利用して確認する

ざっとこの 4 つの方法があります。
人によって違うとは思いますが、個人的に一番分かりやすいというか、間違いがない方法は 1 です。

1. 当該チャンネルの詳細情報モーダルウィンドウから Slack チャンネル ID を確認する

対象

  • Slack デスクトップアプリ
  • Slack ウェブアプリ（ブラウザー）

手順

  1. Slack チャンネル ID を確認したいチャンネルに移動する
  2. チャンネルのメインパネルの方にあるチャンネル名をクリックする
  3. チャンネル詳細情報がモーダルウィンドウで表示される
  4. モーダルウィンドウの最下部からチャンネル ID が確認およびコピーできる
つづきをみる

[Terraform] Docker 内で `terraform init -upgrade` したときに `no such host` が発生

元々は Intel Chip の Mac から実行していた Terraform 環境を久しぶりに弄る機会がありました。

構築時と当時と違うのはぼくの端末が M1 Mac になっていることで、何かしら対応してないよーと言われる覚悟はしていましたが、案の定当時入れた SOPS のバージョンが ARM ベースに対応していませんでした。

# terraform init
 ~
 ~
    Provider registry.terraform.io/carlpett/sops v0.6.2 does not have a package available for your current platform, linux_arm64.
 ~
 ~

というわけで、対応バージョンをググっていると このやり取り から この対応 でサポートされたということなので、0.6.2 から 0.6.3 にアップグレードすることを決意しました。

ところがどっこい。

# terraform init -upgrade
 ~
 ~
    docker: Error response from daemon: Get https://registry-1.docker.io/v2/: 
           dial tcp: lookup registry.terraform.io on 127.0.0.11:53: no such host.
 ~
 ~

外に出ていけていない…。

ネームサーバーを変更（ /etc/resolv.conf ）して解決しました。

# /etc/resolv.conf
#nameserver 127.0.0.11
nameserver 8.8.8.8

久しぶりに弄る環境は怖い怖い…というお話でした。

[Terraform] destory するときに AWS Lambda@Edge がなかなか削除されない件

CloudFront で Basic 認証をかけたり、サブディレクトリー以下のデフォルトアクセスを index.html にしたりするには Lambda@Edge を利用しますよね。

独自ドメイン当てたり、HTTPS 対応したりするのを手動でやっていると抜け漏れなどがあり、意外と面倒になってきたりします。

そんなときに Terraform を使うわけですが、何度も環境を作り直すため、作っては壊したりを繰り返していると度々下記のエラーが発生します。

* aws_lambda_function.fn: Error deleting Lambda Function: Lambda was unable to delete arn:aws:lambda:~~~~~~~ because it is a replicated function. Please see our documentation for Deleting Lambda@Edge Functions and Replicas.
        status code: 400, request id: ********-****-****-********

このエラーはエラーメッセージの通り、Lambda@Edge 関数とレプリカの削除 を見れば原因が分かります。

読んでみてこういう解釈をしました。

CloudFront のエッジロケーションにおいて、Lambda を用いて細かい設定ができるのが Lambda@Edge ですので、エッジロケーションに実行する関数のレプリカが作られるのでしょう。 そのレプリカは CloudFront から外されたタイミングで削除依頼が出され、その削除には数時間かかるということみたいです。

つまりは terraform destory 一発では消せないということですね。

一度、destroy を実行したら時間をおいて実行、というのを完了するまで繰り返す他なさそうですね。

参考

Bot: Cincraw Crawler - Mozilla/5.0 (compatible; Cincraw/1.0; +http://cincrawdata.net/bot/)

このユーザーエージェントは、自分の管理するサービスでたまに見かけるものです。

Mozilla/5.0 (compatible; Cincraw/1.0; +http://cincrawdata.net/bot/)

株式会社 CINC さんの開発したクローラーのようです。 目的はかかれていないですが、アクセスログを追う限りは非常に礼儀正しいクローラーです。

技術検証用なのでしょうかね？

Cincraw Crawler のクローリングポリシー

Homebrew: インストール先のディレクトリーを /usr/local 以外に指定する方法

Mac ユーザーのエンジニアなら多くの人が Homebrew を使うと思います。
個人的には root 権限が要らないユーザーホームディレクトリー直下に置くのがおすすめです。

$ mkdir -p .homebrew/
$ curl -L https://github.com/Homebrew/brew/tarball/master | tar xz --strip 1 -C ~/.homebrew
$ cat << 'EOF' >> ~/.bash_profile
export PATH=$HOME/.homebrew/bin:$PATH
export HOMEBREW_CACHE=$HOME/.homebrew/caches
EOF

参考

タグ

リンク