HackMDでGitLab認証を利用する
HackMDは同時編集が便利なコラボレーションツールです。HackMDは認証なしでも十分に使えますが、外部認証を利用するとさらに便利に使えます。公式リポジトリのドキュメントによると、HackMDは以下の認証方式に対応しています。
本稿ではGitLab認証を利用する方法を説明します。
HackMDのデプロイ
HackMDをKubernetesクラスタにデプロイします。公式の stable/hackmd Helm chart を利用すると簡単にデプロイできます。
ここでは構成管理にHelmfileを利用します。
# helmfile.yaml releases: - name: hackmd namespace: devops chart: stable/hackmd values: - ingress: enabled: true hosts: - hackmd.{{ requiredEnv "kubernetes_ingress_domain" }} resources: limits: memory: 256Mi requests: memory: 256Mi persistence: size: 50Gi postgresql: install: false postgresHost: {{ requiredEnv "database_host" }} postgresDatabase: hackmd postgresUser: hackmd postgresPassword: hackmd
環境変数の kubernetes_ingress_domain や database_host は環境に合わせて設定してください。
export kubernetes_ingress_domain=dev.example.com export database_host=xxx.xxx..ap-northeast-1.rds.amazonaws.com helmfile sync
https://hackmd.dev.example.com を開いてHackMDの画面が表示されたら成功です。
これでKubernetesクラスタにHackMDがデプロイされました。
GitLabの設定
GitLabの管理画面で Applications を開き、New application ボタンをクリックします。以下の項目を入力します。
- Name:
hackmd - Redirect URI:
https://hackmd.dev.example.com/auth/gitlab/callback - Trusted: YES
- Scopes:
api
System OAuth applicationsに hackmd が追加されたことを確認します。
HackMDの設定
HackMDでGitLab認証を設定するには以下の環境変数を設定します。
| 名前 | 設定値 | 例 |
|---|---|---|
HMD_DOMAIN |
HackMDのドメイン名 | hackmd.dev.example.com |
HMD_URL_ADDPORT |
HackMDのポート | 443 |
HMD_PROTOCOL_USESSL |
HackMDでHTTPSを利用している場合はtrue | true |
HMD_GITLAB_BASEURL |
GitLabのURL | https://gitlab.dev.example.com |
HMD_GITLAB_CLIENTID |
前項で追加したOAuth ClientのApplication ID | |
HMD_GITLAB_CLIENTSECRET |
前項で追加したOAuth ClientのSecret |
Helmfileを利用している場合は以下のように環境変数を追加します。
# helmfile.yaml releases: - name: hackmd namespace: devops chart: stable/hackmd values: - ingress: enabled: true hosts: - hackmd.{{ requiredEnv "kubernetes_ingress_domain" }} resources: limits: memory: 256Mi requests: memory: 256Mi persistence: size: 50Gi postgresql: install: false postgresHost: {{ requiredEnv "database_host" }} postgresDatabase: hackmd postgresUser: hackmd postgresPassword: hackmd extraVars: - name: HMD_DOMAIN value: hackmd.{{ requiredEnv "kubernetes_ingress_domain" }} - name: HMD_URL_ADDPORT value: "443" - name: HMD_PROTOCOL_USESSL value: "true" - name: HMD_GITLAB_BASEURL value: https://gitlab.{{ requiredEnv "kubernetes_ingress_domain" }} - name: HMD_GITLAB_CLIENTID value: xxx - name: HMD_GITLAB_CLIENTSECRET value: xxx
HackMDのトップページでサインインをクリックした時にGitLabでサインインというボタンが表示されたら成功です。
See Also
WZR-HP-AG300Hのファームウェアを書き換える (macOS)
macOSでWZR-HP-AG300Hのファームウェアを書き換える方法を説明します。DD-WRTの書き込みや純正ファームへの書き戻しに使えます。
まず、WZR-HP-AG300HのLAN側ポートを有線LANでMacBookに接続します。IPアドレスは以下を設定します。
WZR-HP-AG300Hは電源を入れておきます。
NICのインタフェース名を確認します。ここでは en2 とします。
$ ifconfig en2: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
APRテーブルを手動で設定します。
sudo arp -s 192.168.11.1 02:AA:BB:CC:DD:20 en2
$ arp -a ? (192.168.11.1) at 2:aa:bb:cc:dd:20 on en2 permanent [ethernet]
ここで、WZR-HP-AG300Hの電源を入れ直します。すると、数秒後にTFTPのアップロードを実行できるタイミングが来ます。
- USBコネクタのLEDが光る（2〜3秒）
- USBコネクタのLEDが消える
- EthernetポートすべてのLEDが光る（2〜3秒）
- EthernetポートすべてのLEDが消える
- MacBookと接続しているポートのLEDが光る
- TFTPのアップロードを実行できる（4秒間）
下記の記事が分かりやすいので参照してみてください。
TFTPのアップロードを実行できるタイミングがきたら以下を実行します。
echo -e "verbose\nbinary\nput wzr_hp_ag300h_jp_175" | tftp 192.168.11.1
MacBookと接続しているポートのLEDが光ったら何回か実行してみてください。以下のように、最初の数回はエラーが出ると思います。
% echo -e "verbose\nbinary\nput wzr_hp_ag300h_jp_175" | tftp 192.168.11.1 Verbose mode on. mode set to octet putting wzr_hp_ag300h_jp_175 to 192.168.11.1:wzr_hp_ag300h_jp_175 [octet] tftp: sendto: Can't assign requested address % echo -e "verbose\nbinary\nput wzr_hp_ag300h_jp_175" | tftp 192.168.11.1 Verbose mode on. mode set to octet putting wzr_hp_ag300h_jp_175 to 192.168.11.1:wzr_hp_ag300h_jp_175 [octet] Sent 20472060 bytes in 9.4 seconds [17423030 bits/sec]
TFTPのアップロードが完了したら、正面のLEDが赤色になってファームウェアの焼き込みが始まります。数分後に正面のLEDが緑色になれば成功です。
先ほど設定したARPテーブルのエントリを削除します。
sudo arp -d 192.168.11.1
ブラウザで http://192.168.11.1 を開くと見慣れた設定画面が表示されるはずです。
TerraformでプライベートサブネットとNATゲートウェイを管理する
AWSのNATゲートウェイ構成をTerraformで管理する方法を調べたのでまとめます。
NATゲートウェイ構成とは下記のような構成を指します。
次の図は、NAT ゲートウェイを使用した VPC のアーキテクチャを示しています。メインルートテーブルは、プライベートサブネットのインスタンスから NAT ゲートウェイにインターネットトラフィックを送信します。NAT ゲートウェイは、NAT ゲートウェイの Elastic IP アドレスをソース IP アドレスとして使用し、インターネットゲートウェイにトラフィックを送信します。
https://docs.aws.amazon.com/ja_jp/AmazonVPC/latest/UserGuide/vpc-nat-gateway.html
マネジメントコンソールでNATゲートウェイを構成する場合は以下の流れで行います。パブリックサブネットはすでに存在する前提です。
- プライベートサブネットを作成する。
- EIPを確保する。
- パブリックサブネットにNATゲートウェイを作成する。
- ルートテーブルを作成し、デフォルトゲートウェイをNATゲートウェイに向ける。
- プライベートサブネットにルートテーブルをアタッチする。
Terraformの場合は以下のリソースを定義します。
- プライベートサブネット (
aws_subnet) - EIP (
aws_eip) - NATゲートウェイ (
aws_nat_gateway) - ルートテーブル (
aws_route_table) - ルートテーブルの関連付け (
aws_route_table_association)
実装例
具体的なコードを見ていきましょう。
説明を簡単にするため、ここではVPCとパブリックサブネットがすでに存在しており、そこにNATゲートウェイを付け加える場面を考えます。
# すでに存在するVPCを参照 data "aws_vpc" "example" { tags { Name = "example_vpc" } } # すでに存在するパブリックサブネットを参照 data "aws_subnet" "public" { vpc_id = "${data.aws_vpc.example.id}" tags { Name = "example_public_subnet" } } resource "aws_subnet" "private" { vpc_id = "${data.aws_vpc.example.id}" cidr_block = "${cidrsubnet(data.aws_vpc.example.cidr_block, 3, 4)}" tags { Name = "example_private_subnet" } } resource "aws_eip" "nat_gateway" { vpc = true tags { Name = "example_nat_gateway_eip" } } resource "aws_nat_gateway" "private" { allocation_id = "${aws_eip.nat_gateway.id}" subnet_id = "${data.aws_subnet.public.id}" tags { Name = "example_nat_gateway" } } resource "aws_route_table" "private" { vpc_id = "${aws_subnet.private.vpc_id}" route { cidr_block = "0.0.0.0/0" nat_gateway_id = "${aws_nat_gateway.private.id}" } tags { Name = "example_private_subnet_route_table" } } resource "aws_route_table_association" "private" { route_table_id = "${aws_route_table.private.id}" subnet_id = "${aws_subnet.private.id}" }
サブネットのCIDRはべた書きしてもよいですが、ここでは cidrsubnet() を使ってVPC CIDRから自動計算しています。以下のように記述すると、VPC CIDRの上位3ビットをサブネットに確保します。
cidr_block = "${cidrsubnet(data.aws_vpc.example.cidr_block, 3, 0)}"
例えば、VPC CIDRが 172.20.0.0/16 の場合、サブネットのCIDRは 172.20.0.0/19 が割り当てられます。サブネットマスク長が16 + 3 = 19になるということです。
cidr_block = "${cidrsubnet(data.aws_vpc.example.cidr_block, 3, 4)}"
と記述すると、サブネットのCIDRは 172.20.128.0/19 が割り当てられます。/16 の上位3ビットに4（100）を割り当てるので128（1000 0000）になるということです。説明が難しい。
まとめ
TerraformでプライベートサブネットとNATゲートウェイを定義するのは意外と簡単でした。
See Also:
