kkato.dev

CodeCrafters は HTTP サーバーやシェルなどを車輪の再発明するウェブサイトです。C言語で Redis を実装した際に調べた関数や構造体を備忘録としてまとめました。 ソケット通信の全体の流れ サーバー側のソケット通信は以下の順で関数を呼び出します。 flowchart TD A["socket()\nソケットを作成してファイルディスクリプタを取得"] B["setsockopt()\nソケットのオプションを設定（SO_REUSEADDR など）"] C["bind()\nソケットに IP アドレスとポート番号を紐づける"] D["listen()\n接続待ち状態にする"] E["accept()\nクライアントからの接続を受け付ける（ブロッキング）"] F["read / write\nクライアントとデータをやりとりする"] A --> B --> C --> D --> E --> F 各関数のメモ void setbuf(FILE *stream, char *buf) ストリーム（FILE *）に対するバッファリング動作を制御する関数です。例えば stdout ストリームに対して設定すると、そこへ書き込む printf などが影響を受けます。 ストリームの代表的なものは以下の3つで、プログラム起動時に自動で用意されます。 ストリーム 説明 stdout 標準出力。printf はここに書き込む stderr 標準エラー出力。エラーメッセージの出力に使う stdin 標準入力。scanf や fgets はここから読み込む 引数 説明 stream 対象のストリーム（stdout・stderr など） buf 使用するバッファへのポインタ。NULL を渡すとバッファリングが無効になる NULL を渡すと書き込みが即座に反映されます。デバッグ時や、ログをリアルタイムで確認したい場合に使います。 setbuf(stdout, NULL); // バッファなし（即時出力） setbuf(stdout, buf); // buf に指定したバッファを使う int socket(int domain, int type, int protocol) ソケットを作成してファイルディスクリプタを返します。失敗時は -1 を返します。 ...

Prometheusはデフォルトでローカルディスクにメトリクスを保存しますが、長期保存やHA構成を実現するためにリモートストレージが必要になります。代表的な選択肢としてThanos・Cortex・Mimirの3つがあり、業務で検討する機会があったので比較してまとめました。 比較表 Thanos Cortex Mimir 開発元 コミュニティ (元Improbable) コミュニティ (元Weaveworks) Grafana Labs GitHub Stars ~13,800 ~5,750 ~4,400 ライセンス Apache 2.0 Apache 2.0 AGPL-3.0 CNCF Incubating Incubating - データ取り込み Sidecar (pull) / Receiver (push) remote_write (push) remote_write (push) マルチテナント 限定的 (Receiver経由) ネイティブ対応 ネイティブ対応 ダウンサンプリング あり (ネイティブ) なし なし オブジェクトストレージ S3, GCS, Azure, Swift, COS S3, GCS, Azure, Swift S3, GCS, Azure, Swift Star History 各プロジェクトの特徴 Thanos コミュニティ主導でCNCF Incubatingプロジェクトになっています。最大の特徴はSidecarパターンで、既存のPrometheusに手を加えずに横に並べる形でデプロイできます。 ...

Cloudflare Tunnelを使うと、パブリックIPやポート開放なしにKubernetesクラスタ上のサービスをインターネットに公開できます。 今回はCloudflare Tunnelの作成から、cloudflare-tunnel-ingress-controllerを使ってKubernetesのIngressリソースで自動的にトンネル経由の公開を行う設定までをまとめました。 Cloudflare Tunnelの仕組み 通常、クラスタ内のサービスを外部に公開するにはパブリックIPの取得やルーターのポート開放が必要です。Cloudflare Tunnelを使うとクラスタ側からCloudflareへアウトバウンド接続を張るだけで、Cloudflare経由で外部からのアクセスを受けられるようになります。 cloudflare-tunnel-ingress-controllerを使うと、KubernetesのIngressリソースを作成するだけで自動的にCloudflare Tunnelのルーティングが設定されます。通常のIngress Controllerと同じ使い勝手でトンネル経由の公開が可能です。 Cloudflare Tunnelの作成 Cloudflareダッシュボードからトンネルを作成します。 ネットワーク > Tunnels に移動し、「トンネルを作成」をクリックします。 トンネル名を入力します。ここでは kkato.app としました。 トンネルが作成されると、環境のセットアップ画面が表示されます。ここに表示されるトンネルトークンを後ほど使います。 作成が完了するとトンネルの概要が表示されます。 Cloudflare APIトークンの作成 cloudflare-tunnel-ingress-controllerがCloudflare APIを操作するためのトークンを作成します。 CloudflareダッシュボードのAPIトークンページにアクセスし、「Create Token」から「Create Custom Token」を選択します。 以下の権限を設定します。 Account / Cloudflare Tunnel / Edit Zone / DNS / Edit シークレットをGCP Secret Managerに登録 External Secrets Operatorを使ってGCP Secret ManagerからKubernetesのSecretを自動生成する構成にしています。以下の3つのシークレットを登録します。 echo -n "<your-api-token>" | gcloud secrets create cloudflare-api-token --data-file=- echo -n "<your-account-id>" | gcloud secrets create cloudflare-account-id --data-file=- echo -n "<your-tunnel-name>" | gcloud secrets create cloudflare-tunnel-name --data-file=- アカウントIDはCloudflareダッシュボードのURLやトンネルトークンのデコード結果から確認できます。 ...

GitHub Container Registry (ghcr.io) は、GitHub が提供するコンテナイメージのレジストリです。 Public Packages であれば無料で利用でき、GitHub Actions と組み合わせることでデータ転送料金も無料になります。 ghcr.io は2通りの使い方があります。 ローカルから Docker CLI を使ってイメージをビルドしてプッシュする方法 GitHub Actions を使ってコードの変更に合わせて自動でイメージをビルドしてプッシュする方法 今回はGitHub Actions を使って自動でイメージをビルドしてプッシュする方法を紹介します。 GitHub Actions から自動でプッシュする GitHub Actions を使えば、コードをプッシュするだけで自動的にイメージのビルドとプッシュができます。以下はワークフローの例です。 name: Docker Build and Push on: push: branches: - main # GHCR へのプッシュには packages: write が必要 permissions: contents: read packages: write jobs: build-and-push: runs-on: ubuntu-latest steps: # ソースコードをチェックアウト - name: Check out code uses: actions/checkout@v4 # ghcr.io にログイン - name: Log in to GitHub Container Registry uses: docker/login-action@v2 with: registry: ghcr.io username: ${{ github.actor }} # デフォルトの GITHUB_TOKEN を利用 password: ${{ secrets.GITHUB_TOKEN }} # Docker イメージをビルドしてプッシュ - name: Build and push Docker image uses: docker/build-push-action@v6 with: context: . push: true tags: ghcr.io/${{ github.repository }}:latest トラブルシューティング GitHub Actions から ghcr.io にプッシュする際に、以下のようなエラーが出ました。 ...

Kubernetes上でPostgreSQLを運用するためのOperatorが複数存在します。以前どれを選ぶか検討する機会があったので、主要な4つのオペレーターを比較してみました。 比較表 PGO CloudNativePG Zalando StackGres 開発元 Crunchy Data EDB / CNCF Zalando OnGres GitHub Stars 4,400 8,000 5,100 1,400 ライセンス (Operator) Apache 2.0 Apache 2.0 MIT AGPL-3.0 ライセンス (コンテナイメージ) 独自 (制限あり) Apache 2.0 MIT AGPL-3.0 Patroni 使用 不使用 (独自実装) 使用 (Patroni開発元) 使用 CNCF - Sandbox - - Star History 各オペレーターの特徴 PGO (Crunchy Data) Crunchy Data社が開発するオペレーターで、Patroniを使ったHAに対応しています。Operator自体のソースコードはApache 2.0ですが、Crunchy Data が配布するコンテナイメージは独自のライセンス（Crunchy Data Developer Program）で提供されています。50名以上の組織では本番利用に有償サブスクリプションが必要になるため、注意が必要です。自前でイメージをビルドすれば回避できますが、手間がかかります。 CloudNativePG EDBが開発を始め、現在はCNCF Sandboxプロジェクトになっています。Patroniに依存せず、独自のInstance Managerが各Pod内で動作し、Kubernetes APIを直接利用してリーダー選出やフェイルオーバーを行います。ライセンスもOperator・コンテナイメージともにApache 2.0で、制限なく利用できます。Star数も最も多く、コミュニティの勢いがあります。 ...