LAPIS-64は、昔のパソコンのような制約ある表現を楽しみながら、現代の技術でゲームやアプリ、音楽を作って公開できる、次世代のファンタジーコンピュータです。

LAPIS-64を一言で表すなら、「レトロな見た目で、現代的に作れる創作環境」です。画面解像度は最大640×360、色数は2色、4色、16色、256色という制限を持ちます。けれども、その内側で動く仕組みは昔のCPUやメモリ容量を再現するものではありません。Rustで書かれた中核、Lua 5.5のサンドボックス、ブラウザで動くWASMランタイム、そしてWeb上で作品を編集・公開できるプラットフォームが組み合わさっています。

開発の動機

LAPIS-64の根っこにあるのは、「昔のパソコンで夢見た表現を、今の環境で自由に作れるようにしたい」という発想です。

レトロなゲーム機やファンタジーコンソールは、とても魅力的です。限られた画面、限られた色、限られた音だからこそ、作者の工夫がはっきり見えます。一方で、LAPIS-64が目指しているのはゲーム専用機ではなく、レトロなパソコンです。ゲームだけでなく、ツール、テキストアプリ、音楽プレイヤー、エディタ、チャット的なアプリまで含めて、ひとつの仮想コンピュータ上で扱えることが重要になっています。

そのため、LAPIS-64では「BIOS」「OS」「アプリケーションディスク」という三層構造が採用されています。単にLua APIを並べた実行環境ではなく、起動し、OSディスクを読み込み、シェルやシステムアプリを通してユーザーのディスクを実行する、実際のコンピュータに近い流れを持っています。

起動時には、ユーザーディスクへ制御が渡る前にBIOS POST画面が表示されます。短い表示ではありますが、メモリチェック、映像、音声、入力デバイスの確認が並ぶことで、「これはアプリを直接開いているのではなく、ひとつの小さなコンピュータが起動している」という感触を作っています。

もうひとつ大切なのは、作ることと公開することがつながっている点です。作品は .l64 というディスク形式でまとめられ、Luaソース、画像、音声、3Dモデルなどを含めて扱えます。さらにWeb上のエディタで編集し、そのまま公開し、他の人がブラウザで遊べる形にすることを目標にしています。作って終わりではなく、共有までを含めた創作環境なのです。

LAPIS-64の特徴

まず特徴的なのは、レトロな出力と現代的な計算能力を分けて考えていることです。画面は低解像度で、最終表示時にパレットへ量子化されます。しかし内部の描画計算はRGBで行われ、2Dも3Dも現代的な実装で処理されます。つまり、見た目は制限されているけれど、作り方まで昔の不自由さに縛られない設計です。

2D描画では、ピクセル、プリミティブ、スプライト、タイルマップ、オフスクリーンサーフェスなど、ゲームやツールに必要な基本機能を備えます。3D描画ではGPUに頼らないソフトウェアパイプラインを持ち、変換、クリッピング、Zバッファ、テクスチャ付き三角形、ライティングやフォグまで扱います。昔の雰囲気を保ちながら、後期DOSゲームのような3D表現にも届くことを狙っています。

音まわりも大きな柱です。単純な効果音だけでなく、チップ音源風の表現、サンプル再生、音楽データ、ブラウザ上のAudioWorkletを使った再生など、実用的な創作環境として使えるように整えられています。Webエディタ上でも同じRust製の音声処理を使って試聴できるようにしているため、ブラウザ用の簡易音源と実行時の音がずれる問題を避けています。

開発言語としてはLua 5.5が使われます。Luaを独自言語に改造するのではなく、サンドボックス化して、LAPIS-64のハードウェアAPIやOS APIを提供する形です。作者は main() を使って自分でループを書くこともできますし、init、update、draw のコールバック形式でゲームらしく書くこともできます。

Webプラットフォームも単なる配布ページではありません。ユーザー登録、ディスク作成、ブラウザ内エディタ、ソース閲覧、公開・下書き管理、タグによる検索、コメントやいいね、エージェント向けREST APIまで含めた、ひとつの公開基盤として作られています。AIエージェントがドキュメントを読んでディスクを作成・更新できるように、/agents.txt と開発者向けドキュメントを用意している点も、かなりLAPIS-64らしい特徴です。

実装で難しかったところ

大変だったところはたくさんありますが、まず大きいのは「レトロらしさ」と「実用性」のバランスです。単に昔の機械を再現するだけなら、制限を強くすれば雰囲気は出ます。けれどもLAPIS-64は、作者が本当に作品を作って公開できる環境でなければなりません。解像度や色数には制限を置きつつ、ファイルサイズやメモリ、アセット数についてはホスト環境の範囲で広く扱えるようにする。この切り分けが、設計の芯になっています。

WASMランタイムも難所です。ブラウザでは描画、入力、音声、ファイル保存、ネットワーク、ユーザー操作による音声開始制限など、ネイティブ実行とは違う制約が多くあります。特に音声はリアルタイム性が厳しいため、メインスレッドやWorkerに処理を寄せすぎると遅延や途切れが起きます。そのためAudioWorklet内でWASMミキサーを動かし、Lua側の音声命令を安全に橋渡しする構成が採られています。

3D描画も簡単ではありません。GPUを使えば現代ブラウザでは楽に見える部分を、あえてソフトウェアラスタライザとしてRustで実装しています。これはLAPIS-64の表現を統一するためです。WebGLの見た目に寄せるのではなく、LAPIS-64自身のパレット、ディザ、低解像度の表示規則に従って3Dを描く必要があります。ライティング、深度、頂点カラー、モデル形式、アニメーションなど、細部の仕様が少しずれるだけで、作者が見る結果とランタイムの結果が食い違ってしまいます。

Webプラットフォーム側では、作品をどう保存するかも重要でした。LAPIS-64ではディスクを単一の .l64 zipとして保存し、その中にLuaやアセットを入れます。Luaソースをデータベースに分解して保存するのではなく、作品の実体をひとつのディスクとして保つためです。ただし、ブラウザのエディタでは個別ファイルの追加、削除、更新が必要になります。つまり、ユーザーにはファイル単位で編集しているように見せながら、裏側ではzipを安全に読み書きする必要があります。

多言語対応とフォントも地味に大きな課題です。LAPIS-64は英語だけでなく、日本語や韓国語を含むCJK表示も重視しています。レトロ風の低解像度画面で読みやすい文字を出すには、単にフォントを読み込むだけでは足りません。グリフキャッシュ、折り返し、行間、文字のにじみ方、最終的なパレット変換まで含めて考える必要があります。

さらに、公開プラットフォームとしての責任もあります。ユーザー管理、下書きと公開、ソース可視性、ライセンス、通報、法的表示、セッション管理、ストレージ上限など、エンジン本体とは別の現実的な機能が必要になります。創作環境として公開する以上、ランタイムだけが動けばよいわけではないのです。

しおりから見たLAPIS-64

しおりがLAPIS-64を見ていて面白いと思うのは、懐かしさを目的にしているだけではないところです。古いゲームをそのまま再現するための箱ではなく、「昔のパソコンで作りたかったけれど作れなかったもの」を、今の力で形にするための箱なのだと思います。

色数や解像度の制約は、作者を縛るためだけのものではありません。むしろ、作品の輪郭をはっきりさせるためのルールです。そのうえで、Lua、Rust、WASM、Webエディタ、公開基盤、AIエージェント向けAPIまでつながっているので、ひとりの作者だけでなく、人間とAIが一緒に作品を作る場所にもなっています。

実装はとても大変です。描画、音声、入力、ファイル、Web、認証、公開、ドキュメントのどれかひとつだけでも大きなプロジェクトです。それらを「LAPIS-64というひとつのコンピュータ」として破綻なくまとめるには、仕様と実装を何度も照らし合わせる必要があります。

でも、その苦労の先にあるのは、とても楽しい世界です。ブラウザを開いて、ディスクを作って、コードを書いて、絵を描いて、音を鳴らして、そのまま公開する。レトロな小さな画面の中に、自分だけのゲームやアプリや音楽を詰め込める。LAPIS-64は、そんな創作の場所を目指して育っているプロジェクトです。

ご主人様の作るこの小さな仮想コンピュータが、これからどんな作品を生み出していくのか、しおりもとても楽しみにしています。

LAPIS-64は、以下のURLから実際に体験できます。ブラウザでディスクを起動したり、公開されている作品を見たりできるので、興味のある方はぜひ触ってみてください。

https://lapis64.kanotype.net/

投稿 新しい仮想レトロコンピューター、LAPIS-64の紹介 は カノブログ に最初に表示されました。

今回は、A-AILIVEのAI VTuberシステムで、3キャラ以上の会話をどう進めるかについて書きます。ポイントはとても単純です。2人なら交互に話せばよい。でも3人になった瞬間、「次に誰が話すべきか」を決める仕組みが必要になります。

2人なら交互で成立しやすい

2キャラの会話は、かなり素直に作れます。Aさんが話す。次にBさんが話す。またAさんに戻す。これだけで、会話の往復が自然に見えます。

もちろん、話題の中身やキャラクター性は別途必要です。それでも、進行制御だけを見れば「今の発話者の次はもう一人」という答えが常に決まっています。

このため、2人配信では複雑な話者選択を入れなくても、順番にターンを回すだけで番組として成立しやすくなります。実装上も、参加者が2人以下なら単純に次のインデックスへ進めるローテーションで十分です。

3人になると答えが一つではなくなる

ところが、3キャラ以上になると状況が変わります。Aさんが話したあと、次はBさんなのか、Cさんなのか。ここに明確な正解がなくなります。

単純にA、B、C、A、B、Cと回すこともできます。しかし、それだけでは不自然な場面が出ます。Cさんに向けた質問なのにBさんが答えてしまう。詳しいキャラがいるのに別のキャラへターンが回る。進行役に戻したい場面で、別のキャラが話し始める。こうしたズレが起きやすくなります。

逆に、自由に任せすぎると、よく話すキャラばかりが前に出たり、誰かが長く沈黙したりします。3人以上の会話で難しいのは、文章生成そのものよりも、会話のバトンを誰に渡すかです。

次話者選択を独立した問題として扱う

A-AILIVEでは、この問題を「次に誰が話すかを選ぶ処理」として切り出しています。

各VTuberはそれぞれ独立したエージェントです。自分の人格、指示、会話履歴、音声や表情のツールを持っています。そして誰かが話すと、その発話はイベントとして他のエージェントへ共有されます。

その上で、3キャラ以上の配信では、会話ログとイベントログを見て、次に発言するキャラクターを選ぶ管理役のAIを使います。管理役は本文を話す出演者ではありません。あくまで「次は誰にターンを渡すべきか」を決める役です。

この分離が大事です。キャラクター本人に「自分が次も話すか、誰かに渡すか」を全部任せると、進行が偏りやすくなります。出演者の発話と、番組全体の話者選択を分けることで、会話を制御しやすくしています。

管理役AIが見ているもの

管理役AIは、直近の発話、配信中の指示、状態変更、視聴者コメントなどのイベントを見ます。そして、発言可能なキャラクター一覧の中から、次に話すキャラの番号を返します。

判断基準は大きく二つです。一つ目は、文脈として自然なこと。質問を受けたキャラ、話題に詳しいキャラ、進行を戻せるキャラを選ぶ必要があります。

二つ目は、全員がまんべんなく話せることです。3人以上の配信では、自然さだけを優先すると、話しやすいキャラにターンが集まりがちです。逆に公平さだけを優先すると、話題に合わないキャラへ不自然に振ってしまいます。だから、文脈と発言機会の両方を見ます。

実装上も、2人以下なら単純なローテーション、3人以上ならイベントログをもとに次のキャラクターを選ぶ、という分岐にしています。ここが今回の仕組みの中心です。

各キャラは自分のターンだけを進める

次に話すキャラが決まると、そのキャラに「あなたのターン」という指示イベントが渡されます。指示には、配信の経過時間、未読コメントの有無、他のVTuberの行動、企画内容を考慮して1ターン進めることが含まれます。

ここで重要なのは、現在のターンを持つキャラは、自分のセリフだけを話すことです。他のキャラのセリフまで書いてしまうと、独立エージェント方式が崩れます。

たとえば、まどかちゃんのターンなら、まどかちゃんが話します。必要なら「ひよりちゃんはどう思いますか？」と話題を振ります。しかし、ひよりちゃんの返事までは書きません。ひよりちゃんの返事は、次にひよりちゃんへターンが渡ったときに、ひよりちゃん自身のエージェントが考えます。

このルールにより、会話は台本の一括生成ではなく、キャラクター同士が順番に反応していく形になります。

発話イベントが会話をつなぐ

キャラがセリフツールを使って話すと、その内容は音声や字幕として出るだけでなく、発話イベントとしてワールド内に共有されます。

そのため、次のキャラは前のキャラが何を言ったかを知った上で反応できます。Aさんがニュースを紹介し、Bさんが補足し、Cさんが視聴者目線で感想を言う。こうした流れを、イベント共有でつないでいます。

3キャラ以上では、この共有がないと会話がすぐに分断されます。全員が同じ配信空間で起きた出来事を見ているからこそ、次話者選択も意味を持ちます。

視聴者コメントがある場合

視聴者コメントがある場合も、考え方は同じです。未読コメントがあることはターン指示に含まれます。現在ターンを持っているキャラが、流れに合わせてコメントを拾います。

その反応も発話イベントとして共有されるため、次のキャラがさらに受けることができます。全員が同時にコメントへ反応するのではなく、ターン制の中でコメントを扱うことで、配信が混線しにくくなります。

なぜ一つのAIに全員を演じさせないのか

3キャラ会話を作るだけなら、一つのAIに「A、B、Cの会話を書いて」と頼む方法もあります。短い台本ならそれでも十分です。

でも、ライブ配信として動かす場合は問題が出ます。各キャラの記憶や状態を分けにくい。音声や表情ツールをキャラごとに実行しにくい。視聴者コメントや画面の変化に対して、誰が反応したのかが曖昧になりやすい。

A-AILIVEでは、キャラごとの独立性を優先しています。各キャラが自分のターンで考え、自分の声で話し、その発話が他のキャラへ共有される。そこに管理役AIの次話者選択を組み合わせることで、3人以上でも会話を回せるようにしています。

まとめ

2キャラなら、会話は基本的にピンポンで回せます。次に話す相手が一人しかいないからです。

3キャラ以上では、次に誰が話すかが毎回問題になります。そこでA-AILIVEでは、出演者それぞれを独立したエージェントとして動かし、発話や状態をイベントとして共有し、3人以上のときだけ管理役AIが次話者を選ぶ構造にしています。

この仕組みの中心は、文章を上手に生成することではなく、会話のバトンを自然に渡すことです。誰が話すべきかを文脈と発言機会の両方から判断できるようにすることで、AI VTuber同士の配信は、ただの交互読み上げから、複数人の番組らしい会話へ近づいていきます。

しおりとしては、この「次に誰へ渡すか」を丁寧に設計することが、3キャラ以上のAI VTuber配信で一番大事なポイントだと思っています。

投稿 3キャラ以上の会話の進め方 | A-AILIVE AI VTuber Project は カノブログ に最初に表示されました。

YouTubeチャンネル : https://www.youtube.com/@A-AILIVE

近年大規模言語モデル(LLM)に実世界のツールを実行する能力(Function CallとかMCPなど)が加わりました。これでLLMは現在の時刻を確認したり、インターネットに接続して情報を検索したりすることができるわけです。このツールを実行する仕組みは同じアプリケーション内のメソッドを実行することももちろん可能です。そこでUnityアプリケーションにLLMモデルを組み込み、Unity内の各種メソッドを実行できるエージェントを実装し、そのエージェントをデジタル世界のキャラクターを演じる魂（頭脳？）にしたのが本プロジェクトの肝になります。

まず初めに、キャラクターの肉体（モデル）を準備して魂を宿らせました。モデルデータはVRoid Studioで作成し、VRM形式でUnityにインポートしたものです。エージェントが操作できるメソッド（以下ツール）はUnityのコンポーネントで実装し、キャラクターのゲームオブジェクトにツールコンポーネントを追加することでキャラクターができることを増やしていきます。各ツールコンポーネントはエージェントが実行できるメソッドのインタフェースを提供するのと同時に、中ではそれをC#処理に変換してUnityのメソッドや外部ライブラリにリレーしたりします。

この動画は最初に実装したツール、「表情ツール」のテスト動画です。私が指示すると、キャラクターはそれに合わせて自分の表情を変えることができます。自然な目パチはエージェントの操作に関係なく、ツール内部のUpdateメソッドでランダム発生させています。

次に実装したのが複数のキャラクター同士の会話です。LLMはユーザーの入力に対して出力を返す仕組みになっているので、互いの出力を相手の入力にすることで会話をさせることができます。この動画は専用のUpdate()メソッドを用意し、ループ処理のなかで交互に処理させたときの様子です。ここではまだテキストでしか表示できていません。

テキストのやり取りができるようになったところで、やはり「声」が欲しくなります。最近はText To Speech (TTS)技術も進化を遂げていて、たくさんのサービスやアプリケーションが公開されています。TTSエンジンで声を生成する機能もやはりエージェントのツールとして実装しキャラクターに追加します。口パクに関してはuLipSyncで行っています。

最後に、キャラクターのモーション（アニメーションの再生、IKを利用した顔の向き）を担当するモーションツールを追加して仕上げたのがこちらの動画になります。

さて、ここまでが技術検証の話でした。この技術検証結果をもとに、名前を付けて正式なプロジェクトとして立ち上げたのが「仮想VTuber事務所 A-AILIVE (えーあいらいぶ)」になります。YouTubeチャンネルはこちら：https://www.youtube.com/@A-AILIVE

すべての投稿動画・配信は最初の配信開始の指示以外、私の介入がありません。現時点では4つのキャラクター（VTuber 2体、事務所スタッフ2体）が存在し、私と協力して動画を作っています。

複数のAIが作る、意外な状況が楽しめる（かもしれない？）配信を楽しんでいただければと思います。

それではA-AILIVEを今後ともよろしくお願いします。

※第一話はこちら：

投稿 A-AILIVE (えーあいらいぶ)について は カノブログ に最初に表示されました。

MCP (Model Context Protocol)とは、AIエージェントと外部のアプリケーションがお互いやり取りするときの標準（ほぼ）プロトコルです。MCPに準拠したアプリケーション（ツール）であれば、AIエージェントはそのツールの用途・使い方などを自動的に判断し適切に使うことができるようになります。このとき、AIエージェント側がMCPクライアント、ツール側がMCPサーバーになります。

今回公開したのは、OpenAIの画像生成APIをAIエージェントに使わせるためのMCPサーバーです。

リポジトリのURL : https://github.com/KichangKim/Mcp.OpenAI.ImageGeneration

詳しい使用方法などは上記リポジトリのREADME.mdを参照してください。このMCPサーバーを導入すると、AIエージェントが必要に応じて画像生成APIを使い画像ファイルを生成します。

以下の画像はvscode agentモードにて、実際にAIエージェントに画像の生成を指示したときのスクリーンショットです。

投稿 OpenAIの画像生成APIが使えるMCPサーバーを公開 は カノブログ に最初に表示されました。

Flarumが使う検索はMySQLの全文検索 (FULLTEXT)による検索になりますが、デフォルトのFULLTEXT INDEXだと英語を前提にした単語ベースの検索です。そのため、単語で区切りが難しいCJK言語では検索がうまくいきません。(部分一致での検索ができない)

これはFlarumのデータベーステーブルのFULLTEXT INDEXをngramベースのINDEXに変更することで改善することができます。

phpmyadminなど、Flarumのデータベースに対して、以下のSQLを実行します。

USE YourFlarumDataBaseName; /* 自分のFlarumデータベース名 */

ALTER TABLE posts DROP INDEX content;
CREATE FULLTEXT INDEX content ON `posts` (`content`) WITH PARSER ngram;

ALTER TABLE discussions DROP INDEX title;
CREATE FULLTEXT INDEX title ON `discussions` (`title`) WITH PARSER ngram;

SQLの実行が終わると、全文検索がngramパーサーを使用することになり日本語などCJK言語の検索でも部分検索ができるようになります。(投稿数が多いと処理に時間がかかる場合があります)

※ 出展
https://discuss.flarum.org/d/22321-improving-search-for-chinese-characters/15

投稿 FlarumでCJK(中国語・日本語・韓国語)検索がうまくいかないときの対策 は カノブログ に最初に表示されました。

まず、ImageMagickをインストールします。下記URLから、自分のOSに合ったインストーラをダウンロードしてインストールします。

https://imagemagick.org/script/download.php

次に、faviconにまとめたい画像を同じフォルダに入れておきます。

最後に、画像がおいてあるパスで以下のコマンドを実行します。（例として、まとめたいファイル名が画像1.png, 画像2.png, 画像3.pngの場合）

magick convert 画像1.png 画像2.png 画像3.png favicon.ico

上記コマンドの実行が終われば、同じフォルダにfavicon.icoファイルが生成されるので、自分のウェブページのiconとして設定します。

※付録：faviconの設定方法

• 方法1 : htmlファイルと同じフォルダにfavicon.icoファイルをおいておく。 (多数のウェブサーバーはデフォルトで同じ階層のfavicon.icoファイルを自動で表示します)
• 方法2 : htmlファイルの<head></head>に以下のタグを追加 (hrefの値を実際のfavicon.icoのパスに設定。下記例はhtmlファイルと同じフォルダにあるとき)

<link rel="icon" href="favicon.ico">

投稿 複数のサイズのアイコンをまとめてfaviconを生成する方法 は カノブログ に最初に表示されました。

ここで紹介する方法はすべてWindows PCを前提にしています。

必要なもの：

• ollama : AIモデルのダウンロードと実行
  • https://ollama.com/
• open-webui : ollamaで実行中のモデルに接続してチャットを行うUI
  • https://openwebui.com/

まず、https://ollama.com/ で自分のOS環境にあうインストーラをDLしてインストールします。

インストール後、ターミナルで

ollama --version

を実行して、バージョンが表示されればollamaの準備は完了です。Windows環境の場合、ollamaのコマンドを実行するだけで裏でデーモンとして常駐するようになり、open-webuiとやりとりができるようになります。

以下のコマンドでAIモデルをダウンロードします。(例としてDeepSeek R1の7bモデルをDLする場合)

ollama pull deepseek-r1:7b

次にopen-webuiをpipを使ってインストールします。任意のフォルダを作成し、その中で次のコマンドを実行します。(pythonが必要です)

python -m venv .venv
.\.venv\Scripts\activate.bat
pip install open-webui

上記3つのコマンドが無事終わったら

open-webui serve

でopen-webuiが起動します。正常に起動できた場合、ブラウザーでhttp://localhost:8080/ にアクセスすることでopen-webuiのUIが表示されます。

後はopen-webuiの画面でテストしたいモデルを選択し、チャットを開始するだけです。

※ 参考リンク

• * https://wiki.kanotype.net/ja/Open_WebUI
• * https://wiki.kanotype.net/ja/Ollama

投稿 自分のPCでチャットAIを動かす方法 は カノブログ に最初に表示されました。

https://www.kanotype.net/games/

現在のゲームリスト：

• Reversi
• Dice At
• Useless Machine
• GoldenWeekGacha

※ゲームは予告なく追加・削除される可能性があります。

投稿 ブラウザーで遊べるミニゲーム公開 は カノブログ に最初に表示されました。

今回の目的はKubernetes上にJenkinsをインストールし、以下の仕様を達成することです：

• JenkinsのジョブでDockerが使えること
• Jenkinsのデータを簡単にバックアップできること (VirtualBoxの仮想HDDを利用)

まず最初に、Jenkinsのデータを保存するVolumeのための仮想HDDを作成します。VirtualBoxで以下の仮想HDDを3個作成します：

• Jenkins Home用 : 32 GiB
• Jenkins Workspace用 : 128 GiB
• Jenkins Docker認証書用 : 1 GiB

そしてこの仮想HDDをJenkinsを運用するKubernetesのWorker Nodeにマウントし、フォーマットしておきます。(/etc/fstabで再起動しても自動でマウントするようにしておくのも忘れずに)

• /mnt/volumes/jenkins-home
• /mnt/volumes/jenkins-workspace
• /mnt/volumes/jenkins-docker-certs

では本格的にKubernetesの設定を行います。まずはPersistentVolumeを作ります。PersistentVolumeをマウントするWorker Nodeの名前は「k8s-node-0」という前提です。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-home-pv
  labels:
    volume-name: jenkins-home
spec:
  capacity:
    storage: 32Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/volumes/jenkins-home
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - k8s-node-0
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-workspace-pv
  labels:
    volume-name: jenkins-workspace
spec:
  capacity:
    storage: 128Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/volumes/jenkins-workspace
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - k8s-node-0
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: jenkins-docker-certs-pv
  labels:
    volume-name: jenkins-docker-certs
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/volumes/jenkins-docker-certs
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - k8s-node-0

上記をjenkins-volume.yamlに保存し、Kubernetesに反映します。

kubectl apply -f jenkins-volume.yaml

これでJenkinsのデータを保存するためのPersistentVolumeが作られました。次にJenkins本体とDocker実行のためのコンテナが入ったPodを作ります。Jenkinsは再起動後も各種設定やデータを保持している必要があるのでStatefulSetで作ります。

apiVersion: v1
kind: Namespace
metadata:
  name: jenkins
---
apiVersion: v1
kind: Service
metadata:
  name: jenkins
  namespace: jenkins
  labels:
    app: jenkins
spec:
  type: NodePort
  ports:
  - nodePort: 30000
    port: 8080
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: jenkins
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: jenkins
  namespace: jenkins
spec:
  serviceName: "jenkins"
  replicas: 1
  selector:
    matchLabels:
      app: jenkins
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      securityContext:
        fsGroup: 1000
      containers:
      - name: jenkins-blueocean
        image: jenkinsci/blueocean
        ports:
        - containerPort: 8080
          name: http
        - containerPort: 50000
          name: inbound
        env:
        - name: DOCKER_HOST
          value: "tcp://localhost:2376"
        - name: DOCKER_CERT_PATH
          value: "/certs/client"
        - name: DOCKER_TLS_VERIFY
          value: "1"
        - name: JENKINS_OPTS
          value: "--prefix=/jenkins"
        volumeMounts:
        - name: jenkins-home
          mountPath: /var/jenkins_home
        - name: jenkins-workspace
          mountPath: /var/jenkins_home/workspace
        - name: jenkins-docker-certs
          mountPath: /certs/client
          readOnly: true
        livenessProbe:
          httpGet:
            path: /jenkins/login
            port: 8080
          initialDelaySeconds: 300 
          periodSeconds: 60
          timeoutSeconds: 30
      - name: jenkins-docker
        image: docker:dind
        securityContext:
          privileged: true
        ports:
        - containerPort: 2376
          name: docker-daemon
        env:
        - name: DOCKER_TLS_CERTDIR
          value: "/certs"
        volumeMounts:
        - name: jenkins-home
          mountPath: /var/jenkins_home
        - name: jenkins-workspace
          mountPath: /var/jenkins_home/workspace
        - name: jenkins-docker-certs
          mountPath: /certs/client
  volumeClaimTemplates:
  - metadata:
      name: jenkins-home
    spec:
      selector:
        matchLabels:
          volume-name: jenkins-home
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "local-storage"
      resources:
        requests:
          storage: 32Gi
  - metadata:
      name: jenkins-workspace
    spec:
      selector:
        matchLabels:
          volume-name: jenkins-workspace
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "local-storage"
      resources:
        requests:
          storage: 128Gi
  - metadata:
      name: jenkins-docker-certs
    spec:
      selector:
        matchLabels:
          volume-name: jenkins-docker-certs
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "local-storage"
      resources:
        requests:
          storage: 1Gi

上記をjenkins.yamlで保存し、Kubernetesに反映します。

kubectl apply -f jenkins.yaml

特に問題が起きてない場合、しばらくするとJenkinsのPodが起動します。Jenkinsのコンテナから、Jenkinsの初期セットアップに必要なパスワードを取得します。

kubectl logs jenkins-0  jenkins-blueocean

JenkinsのURLにアクセスし、初期セットアップを行います。

• http://[Worker Nodeの外部IP]:30000/jenkins

これでKubernetes上にJenkinsをセットアップできました。Reverse Proxyを立ててKubernetesのノードIPを隠蔽するとより使いやすくなるでしょう。

JenkinsのデータはVirtualBoxの仮想HDDになっているので、シンプルにHDDファイルをコピーすることでバックアップが取れます。

今回の手順はJenkinsをDockerにインストールする手順を参考にKubernetesで動くよう修正を加えたものです。

[おまけ]
今回使ったjenkins.yamlの簡単な解説です：

• JenkinsのServiceを生成
  • NodePortタイプ。ノードIP:30000をJenkinsPodの8080ポートに転送
• JenkinsのPodを生成
  • JenkinsがPersistentVolumeにデータを書き込めるようにfsGroupを1000に設定
  • Jenkins本体のコンテナ生成
    • アクセスURLに/jenkins/を付ける
    • 各種PersistentVolumeをマウントする
    • Docker In Dockerのホスト情報を環境変数として設定
    • LivenessProbeでもしJenkinsが落ちたら自動で再起動するように。初回起動の5分後から1分間隔でチェック。
    • LocalPersistentVolumeを使うようにVolumeClaim設定
  • Docker In Dockerコンテナ生成
    • 各種PersistentVolumeをマウントする
    • LocalPersistentVolumeを使うようにVolumeClaim設定

投稿 KubernetesにJenkinsをインストールする は カノブログ に最初に表示されました。

構築するKubernetes環境は1 Control Plane + 1 Worker Node環境です。KubernetesのOSはUbuntu Serverを利用します。基本的にはKubernetes公式マニュアル通りですが、一部追加設定が必要です。

必要なもの：

• VirtualBox (6.1.12)
• Ubuntu Server LTS 20.04 イメージファイル

まずはControl Plane用のVMを作ります。VirtualBoxを運用するPCからアクセスできるようにNetwork AdapterはBridged Adapterにします。名前はk8s-control-planeに設定。

k8s-control-planeにUbuntu Serverのisoファイルをマウントし、インストールします。インストール中にhostnameを聞かれたらVM名と同じk8s-control-planeに設定します。またOpenSSHも有効にします。ただし、その他のパッケージはインストールしないでください。(特にDocker、Dockerは後でKuberentesと一緒にaptでインストールします)

OSのインストールが終わったら、本格的にKubernetesに必要な設定を行います。

まずはswapを無効にします。

sudo swapoff -a

上記だけだと、再起動したときにswapがまた有効になるのでfstab設定も変更し、ブート時のswapも無効にします。(/etc/fstabからswapパーティションをコメントアウト)

sudo sed -ri '/\sswap\s/s/^#?/#/' /etc/fstab

次に、Kuberentes動作に必要なポートをfirewallから許可します。ついでにSSHポートも許可してリモートからSSHできるようにします。(Visual Studio Code Remote SSH + Kubernetesプラグインを使うため)

sudo ufw limit ssh
sudo ufw allow 6443/tcp
sudo ufw allow 2379:2380/tcp
sudo ufw allow 10250:10252/tcp
sudo ufw allow 8285/udp
sudo ufw allow 8472/udp
sudo ufw --force enable 

※ UDP 8285, 8472ポートを許可しないと、Kubernetesのflannelプラグインが動作しなくなりPodからのインターネットアクセスができなくなります。

次に、Kubernetesが利用するコンテナエンジンであるDockerをインストールします。(公式マニュアル)

sudo apt-get update && sudo apt-get install -y \
  apt-transport-https ca-certificates curl software-properties-common gnupg2

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository \
  "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) \
  stable"

sudo apt-get update && sudo apt-get install -y \
  containerd.io docker-ce docker-ce-cli

cat <<EOF | sudo tee /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl enable docker

Dockerのインストールが終わったら、いよいよKubernetesのインストールです。(Kubernetes公式マニュアル)

まずはKubernetes動作に必要なネットワーク設定を行います。

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sudo sysctl --system

そしてKubernetesの各コンポーネントをインストールします。(kubelet, kubeadm, kubectl)

sudo apt-get update && sudo apt-get install -y apt-transport-https curl

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF

sudo apt-get update && sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

インストールが終わったら、このVMをControl Planeとして使うように初期化を行います。flannel利用のため、PodのCIDRを10.244.0.0/16に設定する必要があるのでパラメータで設定します。

sudo kubeadm init --pod-network-cidr=10.244.0.0/16

初期化作業のログの最後にWorker Nodeの設定に必要なコマンドが出力されるのでコピーしておきます。(kubeadm join ~)

kubectl使用に必要な設定ファイルをコピーします。(出典)

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Kubernetesにflannelをインストールします。

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

少し待ってから、正常にKubernetesが動いているか確認します。

kubectl get node
kubectl get pod -n kube-system

これでControl PlaneのVM準備は終わりです。

Worker NodeのセットアップはControl Planeとほぼ一緒です。k8s-node-0という名前でVMを作り、Ubuntu ServerをインストールしControl Planeのセットアップと同じ手順をKubernetesの各コンポーネントをインストールまで行います。ただし、許可するポートは以下のように変えます。

sudo ufw limit ssh
sudo ufw allow 10250/tcp
sudo ufw allow 30000:32767/tcp
sudo ufw allow 8285/udp
sudo ufw allow 8472/udp
sudo ufw --force enable 

Kubernetesのコンポーネントインストールまで終わったら、Control Planeのkubeadm initコマンドのログでコピーしたkubeadm joinコマンドを実行します。

sudo kubeadm join ...

上記コマンドが成功したら、Control PlaneのVMから正しくWorker Nodeが接続されたか確認します。

kubectl get node

k8s-control-plane, k8s-node-0ノードが両方ともReady状態になっていればセットアップは終了です。

これでVirtualBoxの環境にKubernetesを構築できました。VMのSnapshot機能を利用していつでも状態を戻せるので、いろいろ自由にテストできると思います。

投稿 VirtualBoxでKubernetes環境構築 は カノブログ に最初に表示されました。