Tech

こんにちは、chanyou です。 OpenHands を自宅の Kubernetes クラスタで動かしてみました。 構成や、ハマった点とかをメモしておきます。 あくまで自宅の趣味のクラスタでとりあえず動くようにした構成なので、参考程度にお願いします。 定義した Kubernetes オブジェクト 話が早いと思うので、最初に YAML をペタっと貼っておきます。 apiVersion: v1 kind: Namespace metadata: name: openhands labels: app: openhands --- apiVersion: apps/v1 kind: Deployment metadata: name: openhands namespace: openhands labels: app: openhands spec: replicas: 1 selector: matchLabels: app: openhands template: metadata: labels: app: openhands spec: containers: # dind-daemon の postStart が完了してから openhands-app を起動する - name: dind-daemon image: docker:28.0.1-dind env: - name: DOCKER_TLS_CERTDIR value: "" securityContext: privileged: true lifecycle: postStart: exec: command: - "sh" - "-c" - | echo "Waiting for Docker daemon to be ready..." until docker info; do echo "Docker daemon not ready yet, sleeping..." sleep 1 done echo "Docker daemon is ready." - name: openhands-app image: docker.all-hands.dev/all-hands-ai/openhands:0.28 env: - name: SANDBOX_RUNTIME_CONTAINER_IMAGE value: "docker.all-hands.dev/all-hands-ai/runtime:0.28-nikolaik" - name: LOG_ALL_EVENTS value: "true" - name: DOCKER_HOST value: "tcp://localhost:2375" ports: - containerPort: 3000 volumeMounts: - name: openhands-state mountPath: /.openhands-state hostAliases: - ip: "127.0.0.1" hostnames: - "host.docker.internal" volumes: - name: openhands-state persistentVolumeClaim: claimName: openhands-state --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: openhands-state namespace: openhands spec: storageClassName: longhorn accessModes: - ReadWriteOnce resources: requests: storage: 1Gi --- apiVersion: v1 kind: Service metadata: name: openhands namespace: openhands labels: app: openhands spec: type: ClusterIP selector: app: openhands ports: - name: http port: 80 targetPort: 3000 --- apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: openhands-ingress namespace: openhands labels: app: openhands annotations: kubernetes.io/ingress.class: "nginx" cert-manager.io/cluster-issuer: "letsencrypt-prod" nginx.ingress.kubernetes.io/auth-url: "https://oauth2-proxy.example.com/oauth2/auth" nginx.ingress.kubernetes.io/auth-signin: "https://oauth2-proxy.example.com/oauth2/start?rd=https://openhands.example.com" spec: rules: - host: openhands.example.com http: paths: - path: / pathType: Prefix backend: service: name: openhands port: name: http tls: - hosts: - openhands.example.com secretName: openhands-tls 解説 Docker outside of Docker から Docker in Docker へ OpenHands のドキュメント では、以下のようにホスト側の docker.sock をコンテナに渡すことで、ホスト側の Docker で Runtime コンテナの起動を行えるようにしています。 ...

こんにちは、chanyou です。 2024年の datatech-jp のアドカレ では、Data Contract CLI の実装を読み解く という記事を執筆しました。 記事でも触れていましたが Data Contract CLI へコントリビュートしたいと思いつつも、なかなか実現できずにいました。 が、思い切って以前からあったらいいなと思っていた機能の提案と実装をしまして、無事に v0.10.21 で反映されました。 これにより Data Contract CLI の利用シーンがさらに広がりそうなので、今回はその内容を紹介します。 実装した内容 記事タイトルにもある通り、Data Contract CLI の export コマンドに custom format を追加しました。 これにより、Data Contract から Jinja テンプレートを利用して任意の形式で出力できるようになります。 例えば、以下のような Jinja テンプレートファイル template.txt があるとします。 title: {{ data_contract.info.title }} このテンプレートを custom format として出力すると、以下のように変数 data_contract.info.title が展開されます。 $ datacontract export --format custom --template template.txt datacontract.yaml title: Orders Latest 実装した背景と想定されるユースケース 今回の機能により、固有のロジックを注入した出力が容易になりました。 従来は、独自のロジックを組み込んだ出力を行うために専用の Exporter を実装する必要がありました。 その方法は、Data Contract CLI を Python モジュールとしてインポートし、いくつかのクラスを定義するという手間がかかるものでした。 ...

これは datatech-jp Advent Calendar 2024 の20日目の記事です。 こんにちは chanyou です。 先日、 datatech-jp の Data Contract事例共有会 というイベントに登壇させていただきました。 Data Contract の導入の難しさを語り合う貴重な機会でした。 イベントではそこまで触れていなかったですが Data Contract CLI というオープンソースのツールがあります。 Data Contract CLI を使うことで、Data Contract の YAML ファイルの読み書きやカタログ生成が容易に行えます。 Data Contract CLI の実装を読む機会がありましたので、この記事で触れていきたいと思います。 Data Contract CLI とは？ ドキュメントは以下から確認できます。 https://cli.datacontract.com ソースコードは以下で、MIT ライセンスで公開されています。 datacontract/datacontract-cli - GitHub Data Contract CLI の基本的な使い方 インストール pip でインストールできます。 pip install 'datacontract-cli' 依存関係が切り出されており、使いたい機能に応じて追加モジュールをインストールできます。 pip install datacontract-cli[bigquery] インストールすると datacontract コマンドが使えるようになっています。 $ datacontract Usage: datacontract [OPTIONS] COMMAND [ARGS]... The datacontract CLI is an open source command-line tool for working with Data Contracts (https://datacontract.com). It uses data contract YAML files to lint the data contract, connect to data sources and execute schema and quality tests, detect breaking changes, and export to different formats. ╭─ Options ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ --version Prints the current version. │ │ --help Show this message and exit. │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ ╭─ Commands ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ init Download a datacontract.yaml template and write it to file. │ │ lint Validate that the datacontract.yaml is correctly formatted. │ │ test Run schema and quality tests on configured servers. │ │ export Convert data contract to a specific format. Saves to file specified by `output` option if present, otherwise prints to stdout. │ │ import Create a data contract from the given source location. Saves to file specified by `output` option if present, otherwise prints to stdout. │ │ publish Publish the data contract to the Data Mesh Manager. │ │ catalog Create an html catalog of data contracts. │ │ breaking Identifies breaking changes between data contracts. Prints to stdout. │ │ changelog Generate a changelog between data contracts. Prints to stdout. │ │ diff PLACEHOLDER. Currently works as 'changelog' does. │ │ serve Start the datacontract web server. │ ╰────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ できることは出力の通りですが、一通り触ってみましょう。 ...

だいぶ前にこういうポストをしていて、諸々環境が整ってきたので実際にやってみました。 @chanyou0311 のポスト 目新しい情報は特になくて、巨人の肩に乗っかると簡単に Kubernetes で起動できるという話です。 Kubernetes で立てるモチベーション CronJob を定義すれば、バックアップなどの任意の処理を定期的に実行できる 設定値を宣言的に定義できる やはり浪漫…浪漫がある… というわけで、カジュアルにおうち k8s クラスタに立ててみます。 まずはネイティブで試す Minecraft などのゲームサーバーを立てたことがなかったので、どう立てるかわかってない状態でした。 まずは Kubernetes を使わずにサーバーを立ててみます。公式ドキュメントの通りに進めるとサクッと起動できました。 専用サーバーの構築 | Palworld tech guide SteamCMD という CLI ツールをインストールして、適切なパラメータを渡して起動するだけです。デフォルトでは UDP 8211 番で待ち受ける形となっています。 外部ネットワークからアクセスするにはルーターのポートフォワードなどの設定を行うことで可能です。Palworld だと 8211 がデフォルトポートで、このポートが使用されることが多いのだと思います。 Kubernetes 起動への道のりを考える Docker Image を用意する SteamCMD は Windows と Linux に対応しているので、 SteamCMD が使える Docker Image を作ってあげれば Kubernetes で起動できそうです。 で、調べると既に有志により palworld-server-docker というリポジトリが公開されており、活発にメンテナンスされているのがわかります。 thijsvanloef/palworld-server-docker - GitHub このリポジトリで管理されている Docker Image に乗っかるのが簡単そうです。 Kubernetes リソースを用意する いい感じの Docker Image が公開されているので、いい感じに Deployment やら PVC やらのリソースを定義して kubectl apply -f palworld.yml すれば起動できそう感があります。 ...

これは 呉高専 Advent Calendar 2022 - Adventar の14日目の記事です。 大遅刻、大変失礼しました… しっかり埋まっていてすごい。そしてアルゴリズムからハードウェアまで、カバー域広い… 改めて、アドベントカレンダーを通して知らない人とつながれるのでとてもいい文化だなと思ってます。 まえがき 2022年の6月にオープンセミナー2022@広島に「データ分析基盤のはじめかた」というタイトルで登壇させていただきました。 データ分析基盤の構成要素など考え方を中心の内容で、最後にデモを行いました。 セミナーでは実装の詳細に触れることができなかったので、この記事では connpass API をデータソースとしてデータ分析基盤を作って動かす方法を紹介したいと思います。1 この記事を通して、データ分析基盤をもっと身近に感じてもらえると願ったり叶ったりです。 対象読者 データ分析基盤構築の一連の流れが知りたい方 普段は構築済みのデータ分析基盤を使っていて、その実装に興味のある方 デモ こちらにリポジトリを公開しています。 clone して docker-compose build && docker-compose up で動くはずです。気長に待ちながら続きを読んでもらえるとこの上ないです。 データ分析基盤の構成要素 実際に動かす前に、データ分析基盤の構成要素について触れておきます。 基本的な構成要素 データ分析基盤は、基本的には以下の要素で構成されます。 それぞれ、以下のような位置づけになります。 要素名 内容 具体例 データソース データの供給元 Google Analytics の生データやセンサーデータなど データレイク データソースから受け取った生のデータを保存するストレージ S3 や Cloud Storage などのオブジェクトストレージが選定されることが多いです データウェアハウス データレイクの生データを、分析が容易な構造化データとして保存するストレージ BigQuery や Redshift、Snowflake などが選定されることが多いです データマート データを利用しやすいように、データウェアハウス内の構造化データをさらに加工したもの 実体としては、ストレージは基本的にデータウェアハウスと同一になるはずで、データウェアハウス内の一部のビューやテーブルを指してデータマートと呼ぶようになります2 データ活用 データの活用先 機械学習モデルやその実装に利用する Jupyter Notebook、BI ツールなどがこれに当たります データパイプライン 上画像の矢印の部分。データ抽出や変換、ローディングなどを行う役割です fluentd や Embulk、 Airbyte や dbt などの SaaS や OSS がよく挙げられますが、FaaS ベースの独自のスクリプトもデータパイプラインと言えます 具体例としてオブジェクトストレージや列指向データベースなどを挙げていますが、あくまで選定される場合が多いものであって、例えば データレイクにはオブジェクトストレージしか採用してはいけない といったことは全くないです。 ...

Kubespray 使ってみた 呉高専 Advent Calendar 2022 の14日目の記事を担当しているんだけど、せっかくなのでこのブログにポストしたい。 mkdocs serve で立ち上げていただけなので、宅鯖に Kubernetes 入れていい感じに稼働させたいということで色々試してみた。 1年くらい前に kubeadm で Kubernetes クラスタ立ち上げたことがあったけど、ステップ数が多くてトラブルシュートが大変だった。 そして先週からこそこそ Kubespray を試してサクッと立てることができた。便利。 こちらは Ansible と kubeadm がベースになっていて、急がば回れで Ansible のチュートリアル入門だけやって Kubespray 触るようにした。 cert-manager とか dashboard とか、一通りお前使うやろ一式が入れられるようになっていて、ホビー用途の自分には合っていそうな感触。 やったこと おうちKubernetesをそれっぽく加工する話 - MetalLBとかExternalDNSとかcert-managerとか - メモ - RyuSA の記事がやりたいことに合致していたので、記事を参考に Kubespray 経由で環境構築した。 あとは今まで mkdocs serve で立ち上げたいたものを mkdocs build して nginx で static に配信する Docker コンテナ作った。 それから雑に Deployment を定義して、 Service やら Ingress やらも定義して apply して終わり。 ちゃんと計測はしていないけど、もっさり感も軽減したと思う。よしよし。

深く考えずにブログを立ち上げたが、かれこれ一ヶ月も経ってしまった。 本当に勢いだったので、記事にタイトルすら設定していなかった。 mkdocs-material のリファレンスを読んで設定した。 --- title: 記事にタイトルを設定してみた --- # 記事にタイトルを設定してみた こういう記述でよいらしい。 ついでに HTTPS にリダイレクトするようにして、作成日時と編集日時も末尾に表示するようにしてみた。日時は git から取ってきているみたい。よくできている。 ただ記事を予約投稿する機能は mkdocs-material にはないらしい（そりゃそうだ） 実現するには GitHub ActionsでZenn記事の予約投稿を実現する という記事の方法のように、 git push するタイミングを制御してやるとよさそう。 ちなみに Zenn は公式で予約投稿ができるようになっていた。同じような記載で設定できると楽だな… 実行環境やデプロイ方法は相変わらずお粗末なので、引き続き手を加えていきたい。 おわり。

家にサーバーが転がっているので、活かそうと思って余っているドメインでブログを立ち上げた。仕事で散々クラウドアーキテクトやっているので、自宅サーバーで気軽にサービス稼働させるのも楽しい。 構成 現状の構成は簡単で、 MkDocs に material テーマ導入して、雑に Docker コンテナ立ててる。こんなんじゃ実サービスローンチできないけど、誰も困らないと思うので本当に気軽にやっていく。 とはいっても、開発用の mkdocs serve でそのまま公開しちゃってるので、 mkdocs build した静的ファイルを Nginx とかで早めにホスティングしておきたい。 こういうのもクラウドだと簡単なソリューション出ているけど、自宅でやると設定がインフラに紐付いて非常に億劫になってしまう。やっぱり k8s クラスタ立てたくなるなー。 あとは Markdown ファイルを git push して、鯖から git pull しないといけなくて、このあたりの CI/CD パイプライン整えていきたい。 GitHub Actions self-hosted runner で自宅サーバのデプロイをしたら最高だった こういう話も聞いているので、 self-hosted runner として動かすもいいし、 Dagger も気になっているので試したい。 今後 そんな感じで、直近だとこのブログを作りながらやったことを書いていくようになると思う。 おわり。