2021/01/09 インスタンスにパスワードを設定する箇所の誤りを修正しました。kolla-ansibleとは公式ページOpenStack 環境のデプロイメントツールです。更に、完全にカスタマイズ可能であることも大きな特徴です。加えて、CentOS や Ubuntu などの多くの Linux ディストリビューションに対応しているのも大きな特徴と言えます。なお、デプロイには Ansible が利用されます。他にも devstack や microstack など数多くのデプロイメントツールが存在しますが、これらは開発環境向けで、カスタマイズが困難であったり、再起動したら壊れてしまうものなど、扱いにくいのが現状です。また、 kolla-ansible と同様に Ansible を利用して OpenStack 環境の構築を行う openstack-ansible なども存在しますが、こちらも筆者環境での検証では再起動したら壊れてしまうものでした。そこで、今回は kolla-ansible を利用してみることにしました。なお、 kolla-ansible ではすべてのコンポーネントを1つのサーバ上で動作させる all-in-one 構成と、複数のサーバをクラスタリングして利用する multinode 構成を選択することができます。今回は all-in-one 構成を構築してみます。multinode 構成については、次回以降取り扱う予定です。インストール準備kolla-ansible では CentOS や Ubuntu などを利用することができますが、本記事では Ubuntu 20.04 LTS を利用しています。事前に python3 などを用意しておく必要がありますので、必要なパッケージとともに導入します。$ sudo apt update$ sudo apt install python3-dev libffi-dev gcc libssl-dev$ sudo apt install python3-pipインストールされた pip3 が最新バージョンであるか確認します。$ sudo pip3 install -U pip続いて、 Ansible をインストールします。$ sudo apt install ansiblekolla 及び kol

環境前提として、Proxmoxの基本的な構築が完了している必要があります。Proxmox環境の構築方法はこちらをご覧ください。また、Cloud-init Supportを参考にしています。Cloud-initテンプレートの準備本記事では、VMで使用するOSとしてUbuntuを使用します。https://cloud-images.ubuntu.com/でOpenstack向けのCloud-initに対応したイメージが配布されていますので、こちらを利用します。Proxmoxホストのシェルにログインして、上記イメージをダウンロードします。今回はUbuntu 20.04 LTSを使用しますので、こちらをダウンロードしました。# wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img続いて、テンプレートで使用するためのVMを作成します。# qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0先ほどダウンロードしたイメージをインポートします。以下の例では対象ディスクをlocal-lvmとしていますが、適時変更してください。(local-zfsなど)# qm importdisk 9000 focal-server-cloudimg-amd64.img local-lvmインポートしたディスクをscsi0としてVMにアタッチします。先ほどと同様に、local-lvmやvm-9000-disk-0は環境によって異なる場合がありますので、適時変更してください。# qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0続いて、Cloud-initが利用するCDROMドライブを設定します。# qm set 9000 --ide2 local-lvm:cloudinit先ほどアタッチしたディスクをブートディスクとして設定します。# qm set 9000 --boot c --bootdisk scsi0Cloud-initはシリアルコンソールを使用するため、その設定をします。# qm set 9000 --serial0 socket --

4Kゲーミング2020年9月17日に、NVIDIAのAmpereアーキテクチャを採用したGPU、RTX 3080が発売解禁されました。筆者は、深夜販売に突撃して運よく入手出来たので、4Kゲーミング性能について軽くベンチマークを通して見ていきます。RTX 3090 ?RTX3080に続いて、RTX 3090が2020年9月24日に発売解禁となりました。こちらも深夜販売での抽選に参加したところ運よく入手できましたので、こちらも見ていきます。なお、「コスパ」とか言ってはいけません。筆者が泣いてしまいます。ベンチマーク環境ベンチマークには、おなじみ3DMarkを使用します。また、DLSSについてもどのような効果があるのか気になったので、こちらも試してみます。手持ちのゲームでDLSSに対応したゲームが「DEATH STRANDING」ぐらいしか無かったので、参考程度にご覧ください。ベンチマークPCとしては以下のものを使用しています。詳細CPUAMD Ryzen9 3950X 16-Core ProcessorM/BASUS Pro WS X570-ACEMemoryDDR4 Non-ECC UDIMM 16GB x4(64GB) 3200MHzPSU80PLUS GOLD 750WStorageWestern Digital SN550 500GB (M.2 NVMe)GprahicsMSI GTX 1080 AERONVIDIA RTX 2060 FEMSI RTX 3080 GAMING X TRIOZOTAC RTX 3090 TrinityRTX 2000シリーズとの比較ベンチを多く見ますが、GTX世代との比較があまりなされていないように思ったのと、筆者がGTX 1080からの更新のため、GTX 1080との性能差に注目したいところです。また、手持ちにあるGPUの中にRTX 2000シリーズがRTX 2060しか無かったので、参考程度です。RTX 3080 and RTX 3090RTX 3080 FERTX 3090 FECUDAコア8704基10496基RTコア68基82基Tensorコア272基328基ベースクロック1.44GHz1.4GHzブーストクロック1.71GHz1.7GHzVRAM10GB GDDR6X24GB GDDR6X外観ZOTAC R

環境前提として、Proxmoxの基本的な構築が完了している必要があります。Proxmox環境の構築方法はこちらをご覧ください。また、今回は2台のノードでクラスタの構成を行います。クラスタ構成時の注意点Proxmoxのクラスタは、2台のノードから構成することが出来ます。しかしながら、HA構成にしたい場合は3台以上のノードが必要になります。また、一度クラスタに追加したノードの削除について、一度削除したノードを再登録することが出来ません。Proxmoxを再インストールする必要があります。（CLIにてProxmoxを再インストールせずに再登録する方法もあるようです）試しにクラスタを構成する場合は、これらに対して注意が必要です。クラスタ構成の利点クラスタを構成すると、各ノードのWebGUIにアクセスする必要が無くなり、単一のWebGUIからクラスタ内のすべてのノードの操作が出来るようになります。また、マイグレーションが可能になり、NFSなどの共有ストレージ上に配置されたVMであれば、ライブマイグレーションも利用可能になります。(Proxmoxではこれらの機能はすべて無償で利用できます)準備管理用のネットワークとは別に、クラスタ構成に使用するネットワークを設定することが出来ますので、必要に応じてクラスタに使用するNICの設定をしておきます。クラスタの作成まず、元となるクラスタの作成を行います。どのノードで作業してもよいはずですが、今回は「node1」と名のつけたノードで作業します。この作業は、どれか1つのノードのみの作業でかまいません。左側のメニューで「Datacenter」を選択し、「Cluster」を選び、クラスタ情報を表示します。「Create Cluster」ボタンを押します。クラスタ名を決め、「Cluster Name」に入力します。この名前は後から変更することが出来ませんので、慎重に決めてください。また、「Cluster Network」に、クラスタで使用するネットワークを設定します。複数のリンクを使用することで、Failoverなどが可能になるようです。入力が完了したら、「Create」を押して、操作が完了するのを待ちます。「TASK OK」と表示されれば、閉じて問題ありません。これで、先ほどの画面に作成したクラスタの情報が表示されているはずです。クラスタへの参加

準備今回は、Ubuntu 20.04.1 を使用しました。Ubuntuに最初から入っているドライバは使用せず、Mellanox公式から取得したドライバを使用することにします。今回は、MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgzを使用しました。取得したファイルを解凍します。$ tar zxvf MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgz$ cd MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64/解凍されたディレクトリの中にある、mlnxofedinstallを実行します。$ lscommon_installers.pl DEBS LICENSE RPM-GPG-KEY-Mellanoxcommon.pl distro mlnx_add_kernel_support.sh srccreate_mlnx_ofed_installers.pl docs mlnxofedinstall uninstall.sh$ ./mlnxofedinstall実行後、新しいドライバを使用するにはopenibdの再起動が必要な旨のメッセージが表示されますので、指示に従います。Installation passed successfullyTo load the new driver, run:/etc/init.d/openibd restart$ sudo /etc/init.d/openibd restartIPアドレスについて、今回は10.0.0.1/24と10.0.0.2/24を使用し、以下のように直結することにします。10.0.0.1/24 ---------- 10.0.0.2/24OSインストール時にIPアドレスの設定はしていませんので、 Interface は Down な状態になっています。そこで Interface を Up にしますが、設定を保存しておく必要はないので今回はipコマンドを使用しました。$ sudo ip link set enp65s0 upIntef

CD環境を構成したい！と、突然書いてみたわけですが、経緯を少し振り返ってみます。経緯なんてどうでもいいという場合は読み飛ばしてください。こちらで紹介したように、弊宅のオンプレ環境ではKubernetesのクラスタが動いています。こちらのブログやポートフォリオが乗っている本番環境には、Rancherを使用していますが、更新のたびにデプロイ処理を行っていました。また、コードはGithubで管理していますので、GithubへPush後、コンテナイメージを作成しローカルのコンテナレジストリにPushしたのち、Rancher側でのPodの更新が必要な状態でした。そこで、今回は、GithubへPushした後の、コンテナイメージの作成・レジストリへのPush・デプロイまでを自動化してみます。構成ざっくり図にしてみると、こんな感じになりました。Github上のmasterブランチへの変更の検知には、Webhookを使用しています。当然、Webhookを使用していますので、Rancher自体にグローバルから到達可能である必要があります。(Githubとの連携作業は、ローカルIPアドレスのみでも行うことが出来ますが、Webhookが機能しなくなります。その場合、Githubのリポジトリ設定からWebhookの宛先を修正してください。)筆者は、少し変なことをしてWebhookのみグローバルからRancherに到達可能にしています。コンテナイメージのビルドなどのフローは、Rancher自体が持つPipelineと呼ばれる仕組みを利用し、設定を行っています。この設定は、RancherのWebGUI上から行うことが出来ます。作成された設定ファイルは、(今回の場合はGithubに)pushされます。なお、Pipelineの仕組み自体に、DockerRegistryをホストする機能がありますが、今回はすでにオンプレ環境でレジストリが存在するため、そちらを使用するようにしました。もちろん、DockerHubなどのレジストリも設定可能です。このPipelineとしての設定を記したファイルは、.rancher-pipeline.ymlとして保存されます。デプロイでは、ワークロードの設定を記述したYAMLファイルを用意しておく必要があります。すでにワークロードがデプロイされている場合には、Rancher上

bashtopbashtop は、CPUやメモリ・ディスク・ネットワークといったリソースの使用状況や、プロセス一覧などを確認できるCLIツールです。同種のツールとして、 htop などが挙げられますが、 bashtop の特徴はより多くの情報を表示できる点です。インストール方法などは、 bashtop のリポジトリをご確認ください。実行してみるシェルからコマンドを叩くだけです。$ bashtop調子に乗って32C64T環境で実行したからか、表示がずれていますね。このような形で、CPU・メモリ・ディスクに加えて、プロセス一覧を見ることが出来、さらには、ネットワークの通信量も確認することが可能です。htop の場合、CPUやメモリの使用状況を確認することは出来ますが、ネットワークの通信量を確認することが出来ませんでしたが、bashtop では、これらの情報を一括で表示できています。以上、簡単にではありますが、 bashtop の紹介でした。

2023/02/12 最新のProxmoxでの変更箇所について解説記事を挟みました。Proxmox VE とはProxmox VE とは、仮想化環境を提供するプラットフォームの1つです。VM(Virtual Machine)などのホストとして使用できます。似た目的の製品として、VMWare ESXiなどがあります。こちらを利用されている方も多いのではないでしょうか。Proxmox - powerful open-source server solutionshttps://proxmox.com/ちなみに、Proxmox VE は Proxmox Virtual Environment の略です。筆者は1年以上 Proxmox VE を使用していますが、いずれも安定して動作しています。Proxmox VE の特徴大きな特徴として、VMWare ESXiと比較し、ライセンスフリーでほぼすべての機能を利用できる点が挙げられます。無償版でも、VMWare ESXiのようにVMあたりのコア数の制限はありません。また、複数のホストをクラスタリングしたり、HA環境、ライブマイグレーションといった機能も無償で利用することができます。さらに、VMWare ESXiと同様にWebインタフェースを持っていますので、Webブラウザ経由で簡単に管理することができます。Debianベースで開発されていますので、ホストOS上にRAIDコントローラのドライバなども簡単に導入することができるのも、利点といえるでしょう。さらに、VMWare ESXiでは早期にCPUサポートが打ち切られるケースがありますが、Proxmox VEでは基本的にLinux Kernelが動作可能なモノであれば動かすことができます。自宅などで古いハードウェアを利用する際には、有力な選択肢となるでしょう。VM(Virtual Machine)やLXC(Linux Container)に対応します。インストール準備公式サイトより、Proxmox VE のISOイメージをダウンロードしてください。2020年8月12日時点では、Proxmox VE 6.2 が最新でした。容量は863MBとなっています。丁度Debianのイメージと同じぐらいですね。イメージのダウンロードが完了したら、balenaEtcherやdd

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)1年ほど前の構成はこちら最近書いた物理構成はこちら指針これまでの自宅環境では、Hypervisor である Proxmox を利用した仮想化環境を主として構成していました。しかしながら、複数のWebサイトをホストしたりする都合上、仮想マシン(VM)ではスケールに手間がかかります。そこで、学習・検証を兼ねて、kubernetes を用いたコンテナ環境を採用することにしました。また、都合上、仮想マシンも同時に扱える必要がありますので、ハイパーバイザー上の仮想マシンでコンテナ環境を実現するという少し変な構成になっています。(電気代を気にしないならばマシンごとに分ければよいのですが、そうもいかないので)Server Hardware本構成では、物理サーバを3台使用しています。うち2台はHPE製の2Uサーバ、DL380 Gen10を使用し、ストレージには Western Digital 製の Ultrastar DC SS200 (SAS 12Gbps) を使用しています。Hypervisor for VirtualizationHypervisor には引き続き proxmox を利用します。VMWare ESXi を用いない理由としては、無償版においてCPU数の制限があること(8C)、ネットワークインタフェースでのLAG等が出来ないことが挙げられます。Infrastructure with kubernetes物理サーバを2台使用し、それぞれの VM 上にワーカーを乗せています。また、図にはありませんが、コントロールプレーンは物理サーバごとに1つ以上配置しています。これらの物理サーバは 10GbE 2本で接続されています。さらに、 Horizontal Pod Autoscaler による水平方向のオートスケーリングを設定しています。HTTPトラフィックは、 Ingress によるL7ロードバランサーを利用し各Podへの分散を行っています。Registry for ContainerDocker Container 用のレジストリには SUSE がオープンソースで公開している Portus を用いています。また、これらの

Docker Registryをプライベートで利用したいDocker Hub には、Docker イメージをアップロード出来る機能がありますが、アップロードしたイメージは有料会員で無い限りすべてパブリックに公開されます。つまり、Docker Hub 上においてプライベートなレジストリを利用するには、有料会員となる必要があるわけです。しかしながら、個人利用においては自身で作成したイメージをパブリックに公開したくないことも多々あります。そこで、レジストリを自身でホスティングする方法で、自分だけの Docker Registry を構築してみます。 本記事は、自宅オンプレ環境にイメージを展開するためのレジストリを構築するという目的で、TLS等での通信に必要な証明書については触れません。Docker Private Registry をDocker上で実行するDocker Private Registry 自体のイメージは、Docker Hub 上で発見することができます。また、以下のようにコマンドを利用しても検索を行うことができます。$ docker search registryNAME DESCRIPTION STARS OFFICIAL AUTOMATEDregistry The Docker Registry 2.0 implementation for s… 2984 [OK] 事前にイメージを手元にダウンロードしておきたい場合は、pull オプションを利用してください。$ docker pull registryまた、これらの手順を行わなくとも以下のコマンドを実行することで、手元にイメージがない場合は自動的にダウンロードされます。なお、本記事では、registry:latest を使用し、レジストリ用のポートとしてホストのポート5000番をbindしています。$ docker run -d -p 5000:5000 --restart always --name registry -v /mnt/docker/registry:/var/lib/registry registryここでは、Docke