2025-12-31

2025年もお疲れ様でした！振り返り回

はじめに

お疲れ様です。たそ(＠taso_int)です。
年末皆さんどう過ごされてますでしょうか?2025年を振り返りたいと思います。
今年26歳なのですが、今日スーパーでお酒を購入しようとしたら年齢確認をお願いされて、証明するものを所持しておらず購入できませんでした…
お酒を飲むなと言われているかもしれません（笑）

総評

人生で初めての転職をしたこと。
自分なりには頑張ったつもりではあるが、そこまで動けなかったこと。

詳細仕事面

まずは今年切っても切り離せない話、わたくし、今年転職をしました。

本日が最終出社日でした
新卒から入社して、4年間本当にありがとうございました！
色々と経験させていただき感謝しかありません🙇 pic.twitter.com/tOso25m1TW
— taso (@taso_int) 2025年7月31日

なぜ転職したのかとかは色々あるのですが、エンジニア人生として一度は外資IT企業でチャレンジしてみたいという思いがありました。
今回縁があり、外資IT企業に転職することが出来ました。偶然で正直かなり運が良かったと感じてます。

8月から入社して来年1月で6ヶ月目になるのですが、最近研修が終わり、お客様の実装や作業をする機会が始まりました。まだまだ不慣れですが、仕事に励んで戦力になるよう頑張ります。

「転職してよかったか？」という話としてはこれは良かったです。「やらぬ後悔よりやる後悔」通りでした。やるかやるかしかないので、すべてを出し切って取り組んでいます。また、扱う技術領域はすごく変わりましたが、それがいい刺激になっております。

あと個人的にわかってよかったのは自分はそこまで優秀じゃないことに改めて気が付けたのは良かったです。
ONE PIECEでいうゾロVS鷹の目の「この距離はねェだろう!! この遠さはねェだろう!!!」状態でした。
前職では、それなりに頑張っていたし、外資でもなんとかやっていけると思ってましたが完全に打ちのめされました... そして、前職では新卒というレッテルも含めて、部署で大切にされていたのと相当社内の信用貯金があって、私もその信用貯金に甘えていたんだなと気が付きました。

改めて、前職に感謝と今の会社に感謝したいです。

詳細プライベート

筋トレの習慣は続いているのはいいことなのですが、体型改善やウェイトトレーニングの成果がイマイチ出てないです。
もう少し痩せるべきなのですが、最終的にはリバウンドしてしまいました...

仕事がメインになってしまうので、仕方のない話にはなりますがそれでも体型には気を付けます。意図的に出社をしているのですが、出社した方がお菓子を食べて太ってしまう可能性がありそうで震えてます。

あとは土日の使い方をもう少し見直したいです。かなり無駄なことをしている時間が多い気がします。来年の改善ポイントです。

今年はもう少し社外のコミュニティを盛り上げたかったのですが、これもなかなかかみ合わずでうまくいきませんでした。ここも来年はどうにかしたいですね。

最後に

凄い簡単ですが振り返りました。
来年もよろしくお願いします。皆さんの1年がよりよくなりますように
つたない文章ですが、読んでいただきありがとうございました。

来年はちゃんと目標を書きます。今年は書いてなかった…

2025-10-04

【後編】サーバ証明書を作成してみる　Let's Encrypt版

はじめに

お疲れ様です。たそ(@taso_int)です。
10月ということで、年明けまで3ヶ月もないと聞いて震えております。転職してから3ヶ月目で、引き続き研修中です。製品や基礎知識について覚えることが多く苦戦中です。　　

前回はOpenSSLで自己署名証明書を作成しました。今回はブログの後編ということでLet’s Encryptを認証局としてサーバ証明書を作成してみます。

前回のブログはこちらから

taso-int.hatenablog.com

サーバ証明書を自己証明書で作成をしたものの、ブラウザで実際にアクセスしてみると警告が出てしまったというところまでが前回の内容です。できる限り正確な内容を書けるように努めますが、ざっくりな解説にもなってしまうので、ご了承ください。間違っている内容があれば、教えていただけると助かります。

警告が出る理由について

サーバ証明書を自己証明で発行し、それに対してアクセスをした際に警告が出てしまいました。
理由としては、クライアントが検証をした結果、このサーバ証明書が信頼できないと判断されたからです。

信頼できるサーバ証明書を作成するには、信頼できる第三者(認証局)から発行してもらう必要があります。自己証明書の場合、自分自身が認証局になって発行しているため、クライアントにとっては信頼できない証明書になってしまいました。

クライアントはどうやってサーバ証明書を信頼するかを説明します。
HTTPS通信を行う際に、TLSハンドシェイクを行ってから暗号化されたデータのやり取りが始まります。 TLSのハンドシェイク(TLS1.3想定)内で、Certificateという項目で、サーバがクライアントに対して、自身のサーバ証明書と中間証明書を渡します。ここでクライアントは、すでに所持しているルート証明書と合わせて、署名の検証を行います。

https://datatracker.ietf.org/doc/html/rfc8446 より

署名の検証とは何かというと、サーバ証明書や中間証明書には発行元(ここでは認証局)の署名がされています。この署名はKPI(公開鍵基盤)を利用した仕組みになっており、発行元(ここでは認証局)の秘密鍵を利用して、この認証局が発行したことを証明するために、各証明書に署名を行います。この証明書が、発行元(ここでは認証局)が正しく発行しているものかを確認するために、各証明書に含まれている公開鍵を利用することで署名の検証を行います。

文章だとわかりづらいので図にしました。クライアントはサーバ証明書に対して、中間証明書に記載されている発行元(ここでは認証局)の公開鍵を使って署名の検証します。検証をすることで、その証明書は署名元が発行したものだと分かります。中間証明書も同様に署名の検証をすることで、署名元が発行したものだと分かります。最後のルート証明書は、自己署名になっておりますが、これは発行元の認証局がOSによる厳しい審査をした結果、信頼できるものとして扱われます。 (Windowsの例: https://learn.microsoft.com/ja-jp/security/trusted-root/program-requirements )

そのため、ルート証明書が起点となって、それぞれの証明書が信頼できものとして扱われ、結果的にサーバ証明書が信頼できるものとして扱われます。これを信頼の連鎖やトラストチェーンという表現で説明されることが多いです。

そのため、信頼できるサーバ証明書を作成するには、ルート証明書を発行してる認証局(ルート認証局)が信頼している認証局に発行してもらう必要がありました。

証明書を作成してみる

解説は終えたので、サーバ証明書を作成してみます。手順としては以下の通りです。

秘密鍵を作成する
CSRを作成する
CSRをLet’s Encryptに申請する
Let's Encryptよりドメイン認証を受ける
サーバ証明書と中間証明書が発行される

Let's Encrypt

ここで認証局として、利用するのがLet’s Encryptになります。

letsencrypt.org

簡単に説明すると、無料のサーバ証明書を提供している認証局になります。ここに対してCSRを申請して、Let’s Encryptから認証(チャレンジ)を行うことで、証明書を発行することができます。実際に試してみましょう。

環境

証明書環境およびサーバー環境

OCI VM(Ubuntu 20.04.6 LTS)
OpenSSL(OpenSSL 3.0.12 24 Oct 2023)
Certbot(DV証明書作成)
ドメイン(Cloudflare)

コンテナ環境

Docker (Docker version 26.1.3)

CSRの作成

ここは前回同様です。ちゃんと運用するのであればSAN証明書を作成した方がよかったかもです。

秘密鍵の作成

openssl genpkey -algorithm EC -out server.key -pkeyopt ec_paramgen_curve:P-256
chmod 600 server.key

CSRの作成 Common Nameに自身のFQDNを記載します。

$ openssl req -new -key server.key -out 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) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:taso
Organizational Unit Name (eg, section) []:taso
Common Name (e.g. server FQDN or YOUR name) []: www.tasoint.work #FQDN
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Certbotの用意

CertBotを利用することで、Let's Encryptに対してCSRの申請およびLet's Encryptからの認証(チャレンジ)を行うことができます。
本来であれば、サーバ証明書には有効期限がありますが、これを利用することでサーバ証明書の自動更新も可能だったりします。　

CertBotをinstallします。

sudo snap install core; sudo snap refresh core
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot

認証(チャレンジ)

サーバ証明書を発行する際には、その人が本当にそのドメインを利用しているかを確認するために、ドメイン認証が必要になります。 HTTPやDNSによる認証がありますが、認証(チャレンジ)は、種類がありますがDNSのTXTレコードで対応します。最初、利用規約などの確認が入ります。

sudo certbot certonly --csr server.csr --manual --preferred-challenges dns
<抜粋>
Requesting a certificate for www.tasoint.work
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Please deploy a DNS TXT record under the name:

_acme-challenge.www.tasoint.work.　#TXTレコードで設定するFQDN 

with the following value:

hL3JkXvXeJHOC_unb_FxyQcwKxZ5mzCA-0ZbRGQI*** #Token

Before continuing, verify the TXT record has been deployed. Depending on the DNS
provider, this may take some time, from a few seconds to multiple minutes.

CertBotからこのTXTレコードを追加してくださいという依頼がでるので、その通りに追加します。その後にEnterを実行します。

Cloudflareに追加

その通り設定します。

証明書の確認

確認ができるとこれが証明書になります。

$ ls
0000_cert.pem  0000_chain.pem  0001_chain.pem  server.csr  server.key #cert.pemがサーバ証明書、chain.pemが中間証明書
$ openssl x509 -in 0000_cert.pem -noout -issuer
issuer=C = US, O = Let's Encrypt, CN = E7

実際に確認してみる

実際に追加しましょう

サーバ証明書と中間証明書を組み合わせる

cat 0000_cert.pem 0000_chain.pem > fullchain.pem

SSLの設定に埋める

server {
    listen 443 ssl;
    server_name www.tasoint.work;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/server.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    root /usr/share/nginx/html;
    index index.html;

コンテナの再起動をして確かめてみます。iptables関係で2時間ぐらい時間をつぶしてしまいました…

警告が出ずに確認することができました！しっかりLet’s Encryptによって発行されています。

最後に

以前よりも証明書関係に詳しくなれた気がします。ここまで読んでいただきありがとうございました。

2025-09-12

【前編】サーバ証明書を作成してみる　自己署名証明書版

はじめに

お疲れ様です。たそ(@taso_int)です。
皆様いかがお過ごしでしょうか？私は引き続きオンボーディングを受けております。
前職でやった分野と全然違う内容なので、まあまあ苦戦してますが、何とか食らいついています。
今日は前編にOpenSSLで自己署名証明書を作成していきます。
後編でLet’s Encryptを認証局としてサーバ証明書を作成してみます。

そもそもサーバ証明書とは？

サーバ証明書はHTTPSを利用する際に使われるものです。そもそもHTTPSが何かというところを話すと長くなるので、割愛します。

ざっくりHTTPSでは、以下のセキュリティ特性を満たしてます。

・機密性: 送信中のメッセージやデータが第三者に伝わらないようにする
・完全性: データが送信中に改竄されていないようにする
・真正性: 送信している相手が本当に意図した相手であることを確認する

ここで証明書を利用することで、この真正性という特性をみたすことができます。
つまり、証明書をサーバに置くことで、HTTPSによる通信が可能になります。 (TLSハンドシェイク時にサーバ証明書がクライアントに対して送られます)

この証明書は誰でも作ることが可能です。証明書を作成する際に、秘密鍵を作成する必要があります。

証明書を作成してみる

まずは自己証明書を作成してみます。手順としては以下の通りです。

秘密鍵を作成する
CSRを作成する
CSRを申請して、証明書を発行する

CSRとは、証明書を作成するための申請にあたるものです。 3のところで、信頼できる認証局(CA)というところへ申請をする必要があります。今回は信頼できる認証局ではなく、自分が認証局になることで、証明書を発行します。

環境

証明書環境

WSL(Ubuntu 24.04.1 LTS)
OpenSSL(OpenSSL 3.0.13 30 Jan 2024)

コンテナ環境

Docker (Docker version 28.2.2)

秘密鍵の作成

以下のようなコマンドで秘密鍵を作成します。

openssl genpkey -algorithm EC -out server.key -pkeyopt ec_paramgen_curve:P-256
chmod 600 server.key

これで、server.keyが作成されました。これが秘密鍵になります。
ここで-algorithm ECとしてますが、これは楕円曲線暗号（EC）を利用することを意図しており、RSA暗号と比べて、同等のセキュリティレベルをより短いキーサイズで実現できます。 ec_paramgen_curve:P-256では、NIST P-256曲線を使用することを指定しており、これは256ビットのキーサイズであることを表してます。

CSRの作成

これを使ってCSRを作成します。自己署名証明書用なので雑です。

$ openssl req -new -key server.key -out 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) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]:taso
Organizational Unit Name (eg, section) []:taso
Common Name (e.g. server FQDN or YOUR name) []:taso
Email Address []:.

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

証明書の作成

これでCSRが作成できたので、自分で証明書を発行します。

openssl x509 -req -in server.csr -signkey server.key -out server.crt -days 365

HTTPSでアクセスをしてみる

実際にこの証明書を使って、HTTPS接続ができるかどうか試してみます。

Docker詳しくないので、Cloudでコンテナのファイルを作成してもらいます。

nginx.conf

server {
    listen 80;
    server_name localhost;
    return 301 https://\$host\$request_uri;
}

server {
    listen 443 ssl;
    server_name localhost;
    
    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
    
    # SSL設定
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    
    location / {
        root /usr/share/nginx/html;
        index index.html;
    }
    
    # ヘルスチェック用
    location /health {
        return 200 'HTTPS OK\n';
        add_header Content-Type text/plain;
    }
}

index.html

<!DOCTYPE html>
<html>
<head>
    <title>HTTPS Test</title>
</head>
<body>
    <h1>SSL/TLS Test Success!</h1>
    <p>This page is served over HTTPS using your custom certificate.</p>
    <p>Server: Nginx in Docker</p>
</body>
</html>

docker-compose.yml

version: '3.8'
services:
  nginx:
    image: nginx:alpine
    container_name: nginx-ssl-test
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./server.crt:/etc/ssl/certs/server.crt:ro
      - ./server.key:/etc/ssl/private/server.key:ro
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
      - ./index.html:/usr/share/nginx/html/index.html:ro
    restart: unless-stopped

これで以下のコマンドで立ち上げます。

 docker-compose up -d

実際にlocalhostに対してアクセスしてみましょう。

警告が出てますが、これは意図している動作です。 NET::ERR_CERT_AUTHORITY_INVALIDと表示されていますが、これは、ブラウザ側で、この証明書を発行した認証局（CA）を信頼できないと判断して警告を出しています。
今回の場合、自分が認証局になっており、発行をしているため、結果的には信頼できない証明書になってしまいました。 (なぜかは後編で説明します。)

実際は詳細設定からlocalhost にアクセスする（安全ではありません）をクリックすることでアクセスできます。

ちなみにCurlでも確認できます。

curl -k https://localhost/
<!DOCTYPE html>
<html>
<head>
    <title>HTTPS Test</title>
</head>
<body>
    <h1>SSL/TLS Test Success!</h1>
    <p>This page is served over HTTPS using your custom certificate.</p>
    <p>Server: Nginx in Docker</p>
</body>
</html>

最後に

実際に証明書は作成できたものの、警告が出てしまいました。後編でLet's encryptを使って証明書を作成したいと思います。（解説も含め）

2025-08-19

ドメインを購入してみた

お疲れ様です。たそ(taso_int)です。 8月も中盤というところで、いかがお過ごしでしょうか？
私は、8月から新天地ということもあり、オンボーディング中です。
前職とはまた違う技術を業務で扱うので結構難しいですが、頑張ります。

今日はドメインを購入したいと思います。
仕事上で検証する際に自身で利用できるドメインを持っておくとよいと聞いたので購入します。

ドメインとは？

ドメインはインターネット上でコンピューターやサーバーを識別するための階層的な名前を指します。
例えば、www.example.com の場合であれば、example.comがドメインにあたるもので、右から左に向かって階層構造になります。今回であればcomがトップレベルドメイン(TLD)でexampleがセカンドレベルドメイン(SLD)になります。（頂点にルートがありますが省略）

これらドメインはレジストリで管理されており、ドメインを利用するためにはレジストラに対して申請をする必要があります。
レジストラは複数存在しているので、利用者が用途やサービスに応じて申請する形になります。

レジストラの選定

今回はCloudflareからドメインを購入してみます。

www.cloudflare.com

サービスとしての売りは以下のことらしいですが、個人的にはXで購入している人を見かけたので決めました

透明性のある登録料および更新料: 追加費用が掛からなかったり、値段が上がらないなど
広範囲なTLDのサポート: 390以上の人気のTLDに対応している
内蔵型のバックエンデセキュリティ: 堅牢らしい

購入可能なドメインを調べる

すでに利用されているドメインは利用できないので、調べる必要があります。
Cloudflareでは、利用可能なドメインを検索することが可能です。

tasoint.workが安いので購入します。

アカウントの作成

アカウントを作成しました。特に躓くことはなかったです。

Registrant informationの追加

購入画面にて、登録者情報が必要になります。ドメインの所有者記録等で利用するものになります。

購入完了

WHOISのサイトで調べてみる

実際にWHOIS ドメイン検索で調べると追加されていました！

最後に

ドメインの取得ができたので、今度はサイトを立ち上げてみてドメインを使ってみたいと思います。短い記事になりましたが読んでいただきありがとうございました！

2025-07-31

4年間お疲れ様でした。

はじめに

お疲れ様です。たそ(@taso_int)です。
皆様いかがお過ごしでしょうか?

JANOG56が現在開催されていますね。私は今回は行けずです。富士吉田(JANOG51)から参加してたのですが、今回は見送りになりました。次の大阪はできればスタッフで参加したいなと思っております。

今日は報告になります。
本日で勤めていた会社を退職することになりました。退職エントリーはないです。

今後のブログ

引き続きアウトプットはします。
ただ自動化周りやAzure周りのアウトプットは減るかもしれません（笑）。自分のためにブログを書いていることもあるので、自分のためになることを引き続きですかね。
ただ今後も気になるプロダクトなどの記事なんかは書いていこうと思います。

どこ行くの?

私に会うか探してみれば見つかるかもしれません。イベントやコミュニティは怒られない限りは続けていくので、お会いしたときに話せればと思います。

最後に

ここまで読んでいただきありがとうございました。引き続き精進していきますので今後ともよろしくお願いいたします。

2025-04-06

4月のAzure Updates(Networking)

はじめに

お疲れ様です。たそ(@taso_int)です。
4月になり、そろそろ花粉によるデバフがなくなればいいなと感じているこの頃です。
今日は、Azure Updatesから4月の一部更新情報を見てみたいと思っております。

Azure Updatesとは

英語版(https://azure.microsoft.com/en-us/updates)
日本語版(https://azure.microsoft.com/ja-jp/updates)

Azure 製品や機能に関する最新の更新プログラムを入手ができるサイトです。
Filterで製品の機能でフィルタリングしたり、キーワードによる検索も可能です。
個人的にはプレビュー情報を見る時に利用してます。
久しぶりに見ましたがUIが見やすくなった気がします。

4月の更新内容

2025年4月現在の新規また更新済み(New or update)かつ製品(Products)はNetworkingのみに絞ります。

パブリックプレビュー: Private EndpointのVNET制限の引き上げ

azure.microsoft.com

High Scale Private Endpointを利用することで、Azure Private Endpointのローカルネットワークおよびピアリングされた仮想ネットワークのデフォルト制限を引き上げることができるようになりました。

現在では、単一の仮想ネットワーク内にPrivate Endpointを1,000個までしかデプロイしかできず、それ以上のエンドポイントを作成しようとすると、既存のPrivate Endpointを削除するか、サポートリクエストを出して現在の制限を引き上げない限り解決できないエラーになります。さらに、ピアリングされた仮想ネットワーク全体で合計4,000個までのPrivate Endpointをデプロイすることが推奨されているとのことです。

High Scale Private Endpointにアップグレードすることで、単一のVNet内のPrivate Endpointのデフォルト制限が5,000に、ピアリングされた仮想ネットワーク全体では20,000に引き上げることが可能です。

そもそもPrivate Endpointとは、Azure Private Linkと組み合わせて使用される機能になります。 AzureのPaaSサービスに対して、パブリックインターネットを経由せずに、プライベートIPアドレスを使って安全に接続することが可能になります。利用することで、セキュリティの強化であったり、ネットワークパフォーマンスの強化につながります。

ただし、この機能をアップグレードまたはダウングレードすると、プラットフォームの更新がトリガーされ、接続が 1回だけリセットされるとのことで、メンテナンス時に実行することを推奨してます。

learn.microsoft.com

パブリックプレビュー: Application Gateway for Containers または Application Gateway Ungress Controller (AGIC)のCNI Overlay

azure.microsoft.com

Application Gateway for ContainersとApplication Gateway Ingress Controller (AGIC)でCNI Overlayを利用することでできるようなったととのことです。

CNI Overlayを利用することで： VNet IPアドレス空間を節約することが可能になり、結果としてクラスターのスケール数の向上につながります。

AKSがそこまで詳しくないですが、解説をするとAKS クラスターの各ノード上にPodが作成されます。
これに対してApplication Gatewayを使ってアクセスするのですが、直接アクセスするためには各PodがVNet内で一意のIPアドレスを持つ必要があります。 Azure CNIを利用することで、VNetからPodに直接IPアドレスを割り当てます。
ここで問題なるのがこのIPアドバイス空間全体で一意である必要があり、アドレスを確保する必要があります。
また、各ノードに対して、サポートされるポッドの最大数を設定する必要があり、これをもとに同じ数のIPアドレスが、そのノードに対して事前に予約されます。
(例えば、ノード当たり最大40PodsをサポートするAKS クラスターで10ノードの場合は400のIPが必要になる。)
そのため、アプリケーションなどの拡大でPodを増やすときに、アドレス空間の計画もしないといけないことになります。

今回、Azure CNI Overlayがサポートされるようになることで、CNI Overlayでは各ノードだけがVNet IPを使用し、 Pod間通信はオーバーレイネットワーク上で行われるため、使用するVNet IPアドレス数を大幅に削減できます。
そのためより多くのポッドを同じVNetサブネット内にデプロイ可能になります。

1つのノードに対してかなりのPodを作成する方にとってはうれしい機能だと感じております。
CNI OverlayまたはCNIに適切なネットワーク構成を自動的に検出し、追加の設定は不要とのことです。

パブリックプレビュー: Azure Front Door カスタム暗号スイート

azure.microsoft.com

Azure Front Doorが、パブリックプレビューでカスタム暗号スイートをサポートするようになりました。
ビジネスやセキュリティ要件に合わせてTLSポリシーを構成する必要がある場合は、カスタムTLSポリシーを使用できます。
カスタム TLS ポリシーを使用すると、サポートする最小 TLS プロトコルバージョンと、サポートされる暗号スイートを完全に制御できます。

Application Gatewayのカスタム SSL ポリシーと似ている機能かと思いました。

最後に

ここまで読んでいただきありがとうございました。
特にCNI Overlayは業務でも活用できそうな気がしました。
定期的にアップデート情報を見て記事にしていこうと思います。

2025-04-05

技術コミュニティを立ち上げた話

お疲れ様です。たそ(＠taso_int)です。
お久しぶりです。もう4月で驚いてます。時が経つのが速すぎますね。
今日は技術の話ではなく、報告です。

技術コミュニティを立ち上げました

技術コミュニティとして、WAZUG(読み方: わずじー)を立ち上げました。
Wakamono Azure User Groupの略で、Azureを活用する若者たちのコミュニティとしてやっていきます。

wazug.connpass.com

いろいろな技術コミュニティやカンファレンスに参加者やスタッフとして参加して改めて、良さを実感しました。
技術というテーマで人がつながり、知見を得ることができたり、同世代のエンジニアと知り合うこともできたり、違う世界(職種)を知れたりすることができたと感じております。今度は自分がそんな場所を提供できればと思っており、今年コミュニティを作りたいと思いました。

発端としてはコミュニティで知り合った~~からあげクンがアイコンの~~フォロワーがXで「TerraformとAzureの初心者コミュニティを作りたい」とつぶやいていたので、

面白そうだし、自分自身コミュニティ作りたかったので巻き込みました。改めてOKしてくれて感謝しております。

やりたいこと

個人的にWAZUGでやりたいことは以下ですね。私が新卒だったころに享受できたらよかったと思ったことをやれたらと思います。

若手や初心者の登壇の場をつくる
初心者向けのハンズオン
Azureのプロフェッショナルの知見を共有していただく
若いエンジニア同士が知り合ってもらう

イベントやるって

4月24日にイベントやります。
参加者数が今のところ少ないですが、どんな人数であれ開催はします。
ただ、人が多い方がモチベーションにつながりますので、気軽に参加していただけると嬉しいです。

Microsoft Azure なんでも会 #1（LT初心者・初参加の方大歓迎！） - connpass

最後に

まずは1年コミュニティ運営を続けていこうと思っております。応援していただけると幸いです。

はじめに

総評

詳細 仕事面

詳細 プライベート

最後に

はじめに

警告が出る理由について

証明書を作成してみる

Let's Encrypt

環境

CSRの作成

Certbotの用意

認証(チャレンジ)

Cloudflareに追加

証明書の確認

実際に確認してみる

最後に

はじめに

そもそもサーバ証明書とは？

証明書を作成してみる

環境

秘密鍵の作成

CSRの作成

証明書の作成

HTTPSでアクセスをしてみる

最後に

ドメインとは？

レジストラの選定

購入可能なドメインを調べる

アカウントの作成

Registrant informationの追加

購入完了

WHOISのサイトで調べてみる

最後に

はじめに

今後のブログ

どこ行くの?

最後に

はじめに

Azure Updatesとは

4月の更新内容

パブリックプレビュー: Private EndpointのVNET制限の引き上げ

パブリックプレビュー: Application Gateway for Containers または Application Gateway Ungress Controller (AGIC)のCNI Overlay

パブリックプレビュー: Azure Front Door カスタム暗号スイート

最後に

技術コミュニティを立ち上げました

やりたいこと

イベントやるって

最後に

詳細仕事面

詳細プライベート