概要今回は無償のハイパーバイザーである Proxmox VE にて無償版リポジトリを設定する方法について紹介します。Proxmox VE では初期設定でエンタプライズ契約向けのリポジトリが設定されており、そのままではアップデートを実施することができません。この設定は簡単に変更できるほか、以前のバージョンでは CLI からの操作が必要でしたが、最近のアップデートで WebUI から設定が可能となりよりセットアップしやすくなりました。なお、Proxmox VE 自体の構築手順などは過去に記事化していますのでそちらをご覧ください。WebUIから設定を変更するProxmox VE の WebUI にアクセスし設定を変更してきます。該当する設定は Datacenter > hostname(画像だとPVE) > Updates > Repositories にあります。続いて、 https://enterprise.proxmox.com/debian/pve と書かれたものをクリックして選択し、 Disable を押して無効化します。続いて、先ほどの Disable ボタンの左横の Add ボタンを押し表示されたダイアログ上で No-Subscription を選択して Add を押します。これで設定変更は完了です。以前までは CLI からの設定が必須だったのでかなり便利になりました。アップデートを実施する設定変更が完了したので早速アップデートを実施してみます。こちらもWebUIから実施が可能になっています。（もちろん中身は Debian ですので CLI からも実施可能です。）アップデートは先ほど Repositories 開く際に使用したペインの1つ上の階層にある Updates を開きます。上部にある Refresh を押すことで内部で apt-get update コマンドが実行されアップデート確認を実施できます。また、 Upgrade を押すことで apt-get dist-upgrade が実行されアップデートが実施されます。

この記事は、CyberAgent 22 新卒 Advent Calendar 2021の19日目の記事です。さいごに概要本記事では、自宅でサーバーやネットワーク機器を運用する筆者が、普段の運用をどのように行っているかを紹介します。また、後半では運用していく中で発生したトラブル経験などを紹介します。サーバーとはサーバーと言われてどのようなものを想像するでしょうか。一般的に、自宅サーバーなどと言われると自宅に中古のデスクトップPCなどを用意してサーバーとして運用するような形を想像する方が多いと思います。しかし、コンピューターにはサーバー用に設計されたものが存在します。これらはデータセンターなどで運用され、サイズ等が規格化されておりラックサーバーなどと呼ばれています。また、これを搭載するための専用のラックが存在しており、ユニット数(U)でいくつかの種類があります。このラックを使用することで、上方向へ積み上げてサーバーを設置することが可能になります。ラックサーバー自体は当然、一般家庭に設置することを想定したデバイスではありませんから、静音性より冷却性能の方が重要です。そのため、基本的に静音性とは無縁です。（サーバーラックに搭載されたラックサーバーの例）自宅サーバーを運用するメリットでは、デスクトップPCなどを使用する場合を含め自宅でサーバーを運用するメリットは何でしょうか。まず一つ目は、学習機会を得られるということです。AWSやGCPといったパブリッククラウドを利用するのと違い、自宅でサーバーを運用するには、物理レイヤーからすべて自分で設計や構築を行う必要があります。パブリッククラウドが普及した近年では、手間が掛かる事から嫌厭されがちですが、学習することに重点を置けば、より多くの学習機会が得られるというメリットがあると言えます。その中では、ネットワークに関する知識のほか、ハードウェアに関する知識も必要となります。そして、こういったレイヤーの知識は経験も重要です。この経験は、実際に運用していく中で原因切り分けなどを実施することで身に付く部分が多い分野でもあります。もう一つは、シビアにコストを気にする必要が無くなるということです。パブリッククラウドでは、インスタンスの起動時間や通信量による課金でコストが掛かります。例えば、パッケージを再インストールしたい場合などに、追加でコスト

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 --

環境前提として、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」と表示されれば、閉じて問題ありません。これで、先ほどの画面に作成したクラスタの情報が表示されているはずです。クラスタへの参加

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上

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

色々と機材更新やらがありましたが、1年ほど書いていないなと思ったので、書いてみることにしました。前半は機器類の紹介、後半は構成についてです。自宅36Uラック私は一人暮らしをしている学生ですが、自宅に36Uラックを設置しています。その様子を先に。サーバサーバ機器はラック下部にマウントしています。重量のある機器はできるだけラック下部へ設置し、ラック自体の重心を下げるように努めています。自宅のワンルームに設置していますから、地震等でラックが倒壊する可能性をできるだけ抑えるのが目的です。 現在、以下のようなサーバがあります。名称CPURAMHP DL380e Gen8Intel Xeon E5-2420v264GBHP DL380p Gen8Intel Xeon E5-2640v2 x2128GBHPE DL380 Gen10Intel Xeon Silver 4208128GBHPE DL380 Gen10Intel Xeon Bronze 310416GB自作AMD EPYC 7452 32-Core Processor128GBネットワークネットワーク機器は主にラック上部にマウントしています。機器類の管理ネットワークは1GbEで構成し、ストレージ周りは10GbEとしています。使用しているスイッチには40GbEポートがありますから、将来的に40GbEを利用する予定です。(スイッチの紹介、検証等は別途記事にしていますので、アーカイブから御覧ください。)さらに、光ファイバーを2回線引き込んでいます。また、OpenVPNを用いたSite-to-Site VPNによって、VPS及び別のリージョンに設置した機器類について、接続を行っています。各リージョン間の経路情報の交換は、BGPを用いて行っております。 電源夏場のゲリラ豪雨等の一時的な停電・電圧降下に対応するため、1200VAのUPSを1台設置しています。昨年夏の稼働回数は、瞬間的な電圧降下によって15回ほど作動しましたので、重要な役割を担っています。また、15Aのブレーカを搭載したサーバラック用にコンセントバーを背面に設置しております。構成とか現在は、TrueNAS(FreeNAS)を用いたネットワークストレージのみが稼働している状況です。 今まではProxmoxを用いた仮想化環境をメインにしておりましたが、先日まで検