Posts

PostgreSQL16をソースコードからビルドしてみたのですが、いくつかつまづいたポイントがあるので、それらにご紹介します。 PostgreSQL16をソースコードからビルドするためのコマンドは以下のとおりです。前提として M1 Mac (macOS 14.4.1) を使っています。 % git clone git://git.postgresql.org/git/postgresql.git % cd postgresql % ./configure --enable-debug --enable-cassert --enable-tap-tests --prefix=$HOME/pgsql CFLAGS=-O0 % make -j 4 % make install configureコマンドには以下のオプションを指定しています。 デバッグしやすくするためのオプション: –enable-debug –enable-cassert –enable-tap-tests インストール先のディレクトリを指定するオプション: –prefix 参考: https://www.postgresql.jp/document/16/html/install-make.html#CONFIGURE-OPTIONS icu-uc, icu-i18nのパッケージが見つからない icu-uc, icu-i18nのパッケージが見つからないと言われました。 % ./configure --enable-debug --enable-cassert --enable-tap-tests --prefix=$HOME/pgsql CFLAGS=-O0 (省略) checking for icu-uc icu-i18n... no configure: error: Package requirements (icu-uc icu-i18n) were not met: No package 'icu-uc' found No package 'icu-i18n' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix....

以前Kubernetesクラスタを構築するときに、Rocky Linuxでcontainerdをインストールする方法についてあまり情報がなかったので、とても苦労しました。 なので今回はその時に調べた内容を記事にしてみました。 次のコマンドでcontainerdをインストールできます。 # yumにCentOS用のdockerリポジトリを追加する sudo yum config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo # docker-ceリポジトリに含まれているcontainerd.ioのパッケージをインストールする sudo yum install -y containerd.io # containerdのデフォルト設定ファイルを生成する sudo sh -c "containerd config default > /etc/containerd/config.toml" そして最後にcontainerdを有効化します。 systemctl enable --now containerd.service 参考 Using containerd without docker (Installing containerdの部分)

しばらく放置していたNUC上にk8sをインストールして、おうちクラスタを運用していこうと思います。 今回はkubeadmを使ってk8sをインストールしようと思います。 前提 ベアメタル(Intel NUC11PAHi5)上に構築 Control Planex1台とWorkerx3台の4台構成 OSはRocky Linux9.3 ルーター側の設定で固定IPを割り当て 各ノードのスペックは以下 CPU メモリ ストレージ 4コア 16GB 500GB kubeadmのインストール 以下の手順を参考にします。 kubeadmのインストール 「始める前に」にSwapがオフであること、と記載がありますが、swapがオフになっていなかったので無効化します。 sudo swapoff -a ポートの開放 kubernetesのコンポーネントが互いに通信するために、これらのポートを開く必要があります。 RockyはRHEL系なのでfirewall-cmdを使って、Control Planeノードのポートを開放します。 sudo firewall-cmd --add-port=6443/tcp --permanent sudo firewall-cmd --add-port=2379-2380/tcp --permanent sudo firewall-cmd --add-port=10250/tcp --permanent sudo firewall-cmd --add-port=10257/tcp --permanent sudo firewall-cmd --add-port=10259/tcp --permanent ポートが開放されたことを確認します。 sudo firewall-cmd --reload sudo firewall-cmd --list-ports 続いて各Workerノードのポートを開放します。 sudo firewall-cmd --add-port=30000-32767/tcp --permanent sudo firewall-cmd --add-port=10250/tcp --permanent ポートが開放されたことを確認します。 sudo firewall-cmd --reload sudo firewall-cmd --list-ports コンテナランタイムのインストール コンテナランタイムの手順を参考に、各ノードに設定をしていきます。...

ウォンテッドリーに入社して1ヶ月経ったので、色々と振り返ってみようと思います。 転職を考えたきっかけ 前職ではややニッチなテーマに取り組んでいたこともあり、そのまま長く居続けても他の会社でやっていけるか不安でした。また、変化が早い時代なので、会社に依存せず個人でやっていけるだけの実力・スキルを身につけたいと考え、もっと技術力を伸ばせるような会社に移りたいと思うようになりました。 企業選びの軸 企業選びは以下の軸をもとに考えました。 自社でサービスを開発・運用している 技術力の高いエンジニアが在籍している 先進的な技術を扱っている 上記の条件を満たすような会社であれば、もっと技術力を伸ばせると思ったからです。 転職に向けて行ったこと インフラエンジニア / SRE職を希望していたので、主に以下のようなことを行いました。 関連する資格の取得 (AWS SAP、CKA) 個人ブログでの発信 簡単なWebアプリの作成 前職でPostgreSQL、Kubernetesを触る機会があったものの、AWSやTerraformの経験、それに本番環境の運用経験がなく苦労しました。実務での経験不足を補うために、AWSの資格を取得したり、個人ブログで今まで学んだことのアウトプットなどを行うようにしました。また、SRE職などだと自動化のツールなどをGoで書くこともあると思ったので、Goで簡単なTo-doアプリを作成したりしました。 ウォンテッドリーへの入社を決めた経緯 ウォンテッドリーへはスカウト経由で入社しました。（Wantedly Visitに登録したら、ウォンテッドリーからスカウトが来てびっくりしました笑）カジュアル面談で話を聞いていると、PostgreSQLやKubernetesなど今まで培った経験を活かしつつ、新しい挑戦ができそうだったので、選考を受けてみようと思いました。 選考を受ける前だったか、1次面接の後だったか覚えていませんが、Engineering HandbookとCulture Bookをいただきました。まず、開発や会社の文化に関することがこのような形にまとめられているのが素敵だと思いました。そして、内容に関してもエンジニアリングに対して真摯に向き合う姿勢やエンジニアにとても理解のある会社だということが伝わってきて、こんな会社で働いてみたいと思うようになりました。（個人的にはCulture Bookの「変わるエンジニアの定義」が好きです。) また、2次選考として 1 day インターンに参加させていただきました。わずか1日のインターンシップではあるものの、チームメンバーがどんな人なのか、日々どんな業務に取り組んでいるのかなど実際に働くイメージがつき、その後安心して入社することができました。 入社してからの感想 毎日分からないことだらけですが、その分学ぶことが多くてとても充実しています。周りのエンジニアの方々は技術力が高くて、尊敬できる方ばかりです。 オンボーディングに関しては、研修や社内のドキュメントが整備されていて、スムーズに環境に馴染むことができました。分からないことがあるとすぐに聞ける雰囲気があり、ちょっとしたことでもSlackやHuddleで相談できて大変ありがたいです。週2出社なので、対面でのコミュニケーションもできて良い感じです。 びっくりしたことは、会議室の名前がジョジョの奇妙な冒険からつけられていること、白金台のランチの選択肢の少なさ、あとはエンジニアの1割がDvorak使いということですかね笑　今後ウォンテッドリーで取り組みたいこと 今後取り組みたいことは以下の通りです。 Kubernetes, PostgreSQLなどのアップグレード インフラの性能監視・運用改善・障害対応 Goを用いたツールの開発 前職だと実運用を経験していなかったので、システム基盤のアップグレードを経験したいという思いがあります。同様に、性能監視や運用改善、障害対応などインフラエンジニアとして求められている基本的な業務も一通り経験してみたいです。また、ウォンテッドリーのインフラチームは様々なツールをGoで実装しているので、それらの実装を理解し改善していけるだけの力をつけていきたいです。 上記以外にも直近不足している知識(NW、AWS、Terraform、Gitなど)が多いので、日々精進していく所存です！

Kubernetes上でAlertmanagerがちゃんと通知できるか、どんな内容が通知されているのか確認してみようとすると、連携するためのSlackが必要であったり、Emailを送信するにもメールサーバが必要だったりと、意外と気軽に試せないということがありました。 なので、今回はwebhookの機能を使ってNginxにリクエストを飛ばし、リクエストの内容をログから確認してみようと思います。 webhookとは? Alertmanagerのreceiverには以下が指定できます。 Email Opesgenie PagerDuty Pushover Slack AWS SNS VictorOps Webhook Wechat Telegram Webex Webhookとは特定のエンドポイントに対してHTTP POSTリクエストでアラートの情報を送信するというものです。 外部サービスではないので、自分自身でエンドポイントを用意し、自分自身で後続の処理を実装する必要があります。 例えば、以下のように設定します。 receivers: - name: "nginx" webhook_configs: - url: 'http://nginx-svc.default:8080/' webhookの連携先としてnginxを使う 今回はwebhookの連携先としてnginxを使用します。 nginxを使って実現したいことは以下のとおりです。 エンドポイントを用意する リクエスト内容を確認する nginx.confの初期設定をベースにしていますが、そのままだとリクエスト内容を確認することができないので、設定を追加しました。 log_formatで$request_bodyを指定し、/にアクセスした時に$request_bodyがログとして標準出力に出るように設定しています。 しかし、$request_bodyを有効化するにはproxy_passなどの後続処理が必要になります。なので、proxy_passで/trashというエンドポイントにリクエストを転送し、/trashで特に意味のない処理(1x1ピクセルのgifを返す)をしています。 The variable’s value is made available in locations processed by the proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the request body was read to a memory buffer. http://nginx.org/en/docs/http/ngx_http_core_module.html#var_request_body user nginx; worker_processes auto; error_log /var/log/nginx/error.log notice; pid /var/run/nginx....