はてなブックマーク

Macで動くmacOS 13（Ventura）以降とApple Siliconチップ（執筆時点だとM1やM2）の組み合わせを使うと、「Rosetta for Linux」を使えるようになります。ここでいうRosettaとはApple Siliconチップの上でIntel CPU向けアプリを動かすことが可能なRosetta 2のことを指しており、この機能はそれをVMで使ってしまう技術です。 Macでもフリーで使えるVirtualBoxは活躍してくれていましたが、VirtualBoxはx86をエミュレートするソフトウェアであり、Apple Siliconチップには対応していませんでした（現在はM1/M2で動くVirtualBoxが開発中だったりします）。 とはいえ、安定して動くまではまだかかるため、その代替として候補に上がったのがUTM.app でした。名前から誤解される可能性があるのですが、

Kubesharkとは 図は公式 より抜粋 KubesharkはKubernetesのための観測性・監視ツールで、マイクロサービスの動的解析、異常の検出などを実現するツールです。 Wireshark、BPF Compiler Collection（BCC）ツールなどを組み合わせた、Kubernetesを意識したものとお考えください...と説明されています。 Kubesharkは、クラスタ内の一部またはすべてのTCPトラフィックをスニッフィングし、PCAPファイルに記録し、HTTP1.0, HTTP1.1, HTTP2, AMQP, Apache Kafka, Redisなどのアプリケーション層プロトコルを分析できるとのことです。 今回はHTTPに絞って実際に環境を動かしてみて、トラフィックを覗いてみたいと思います。 Kuberentesクラスターの用意 まず、Kuberentesクラスター

2022年10月21日(日本時間)、Ubuntu 22.10 Kinetic Kuduがリリースされました。 主な変更点についてはリリースノートを参照して頂きたいのですが、一般的なユーザーにとって影響するであろうポイントは、SSHサーバーがsystemdのSocket-Based Activation経由で起動されるようになった点でしょう。 wiki.ubuntu.com この変更は、SSHサーバーの待ち受けポートを変更したい場合に影響があります。従来であれば/etc/ssh/sshd_configを直接書き換えていましたが、Ubuntu 22.10ではsystemd.socketのUnitファイルを変更する必要があります。デフォルトでは/etc/systemd/system/sockets.target.wants/ssh.socketというファイルに、以下の記述がされています。このLi

Podman Desktopはアプリケーション開発者向けのコンテナ実行環境とKubernetesを提供するソフトウェアです。WindowsとmacOS、Linuxに対応しているようです。 現在は0.0.6が最新のバージョンです。 podman-desktop.io Docker Desktop有料化からおおよそ一年が経ち、同様のソフトウェアが増えてきましたね（Rancher desktop、Container Desktop、ちょっと用途が異なりますが、Multipassなど）。OSSのDockerやDocker Desktopを含めてどれも好きなんですが、今の所私のお気に入りはRancher Desktopですね。 Multipassはコマンドでなにか操作するようなときにVMを作って、その中で操作しています。Ubuntuのsnapパッケージについては議論があるのは知っていますが、少なくと

CentOS 7上で動かしていたZabbix 4.0を、Ubuntu 22.04に移行しつつZabbix 6.0系にアップグレードしました。Zabbixのインストール自体はなんてことはないのですが、データベースのアップグレードですこし難儀したため、その記録です。 移行元のLAMP環境 OS: CentOS 7.9.2009 Webサーバー: 2.4.6 DB: MariaDB 5.5.68 PHP: 5.4.16 Zabbix: 4.0.42 CentOS 7自体はまだサポート中ですが、新しいZabbixでは新しめのPHPを要求されるため、Ubuntu 22.04で再構築してDBを移行することとしました。 DBは、文字コードがlatin1で作られていたため、今回を期にUTF-8に移行します。これが今回の罠ポイントです。 移行先のLAMP環境 OS: Ubuntu 22.04 Webサーバー

Kubernetes 1.24がリリースされ、dockershimコンポーネントが削除されました。 これはKubernetes 1.24以降のバージョンでDockerをランタイムとして使うことができないことを意味します。 ところで、dockershimが削除されることは結構前から告知されていました（1.20にリリースをもって非推奨になりました）。とうとうそれが今回実行されたということです。 それでは困るという需要に応えるために、Dockerのエンタープライズ事業を継承したMirantisがOSSでcri-dockerdを開発しています。 github.com 今回はこれを使って、KubernetesでDockerをランタイムとして使ってみたいと思います。 動作環境について 今回はテスト環境のベースOSとして、Ubuntu 18.04.6 LTSを使っています。 Ubuntu 22.04 L

このブログではKubeVirtについて何度か取り上げていました。 主にkubeadmでクラスターを作って、KubeVirtを導入する手順もご紹介しています。 tech.virtualtech.jp ちなみになぜKubeVirtを頻繁に取り上げるかというと、筆者がKubeVirtに個人的に興味があるからです。 さて今回はMinikubeを使って、KubeVirtの評価ができる環境づくりを試してみようと思います。 Minikubeを利用することにより、KubernetesでKVM VMを利用できるKubeVirtを手軽に試すことができます。 Minikubeで手軽にKubeVirtを利用できるようになることで、コンテナーとVMでアプリケーションを実行して色々なテストをしたり、 コンテナーとVMでアプリケーションをそれぞれ動かして、連携のテストをしたりなどできるようになるので、おそらく便利だと思

YubiKey 5はPIV (Personal Identity Verification) という規格に対応しています。PIVとは米国政府機関が発行するスマートカードのことで、YubiKeyではこれを操作することができます。 YubiKey 5のPIVは、RSA 1024 / RSA 2048 / ECC P-256 / ECC P-384に対応しています。今回はYubiKey内にECC P-384の鍵を生成し、保存した鍵を利用してSSHログインできるようにしてみようと思います。 検証環境 YubiKey 5C NFC Ver.5.2.7 macOS Big Sur Ver.11.5.2 ツールのインストール YubiKeyのコマンドラインツールykmanと、スマートカードを扱うためのライブラリ、ユーティリティを提供しているOpenSCをインストールします。 $ brew install

2年ほど前にイベントのデモとして登場していた、Raspberry Pi(arm)向けのESXiが、いよいよVMware FlingsでTech Previewの位置づけとしてリリースされていたので、早速インストールして触ってみました。 ちなみに、たまたま仕事でVMware Flingsを開いたら昨日付けでリリースされていたのでめちゃくちゃ驚きました。 ESXi Arm Editionの入手 ESXi Arm Editionは以下のページから入手できます。ISOイメージのダウンロードにはVMwareのアカウントが必要でした。 flings.vmware.com また、同じページからRaspberry Pi向けのセットアップガイド「Fling-on-Raspberry-Pi.pdf」が入手できますので、あわせてダウンロードしましょう。 以下の手順はセットアップガイドを元に解説しているので、公式

VMware vSphere環境にUbuntu Server 20.04のVMを構築している最中、syslogを見たくなって開いてみたらmultipathdのログで埋まっていました。数秒ごとに以下のようなログが出力され続けています。 Jul 2 23:59:45 hoge multipathd[757]: sda: failed to get udev uid: Invalid argument Jul 2 23:59:45 hoge multipathd[757]: sda: failed to get sysfs uid: Invalid argument Jul 2 23:59:45 hoge multipathd[757]: sda: failed to get sgio uid: No such file or directory Jul 2 23:59:46 hoge mult

Longhornは、Kubernetes用の分散型ブロックストレージシステムです。 Longhornの導入により、Kubernetesクラスターでコンテナーアプリケーションに対して永続ボリュームを提供できます。 LonghornはRancherのアプリカタログにあるため、Rancherを一度でも触ったことがあるならお馴染みのソフトウェアだと思います。実際、RancherでLonghornを展開するのは簡単で、アプリカタログからLonghornを選び、Longhornの設定をぽちぽち定義して展開するだけで利用可能になります。 展開後はRancherでコンテナーアプリケーションを展開する際に永続ストレージが必要なときにLonghornを呼び出すだけです。自分で作成したYAMLを使ってコンテナーアプリケーションをデプロイする際は、PersistentVolumeClaimの要求を含めることで永続

Kubernetesは現在、バックエンドエンジンとしてDockerを利用しています。 Podの作成はYAML形式でエディターで書いて、kubectl createコマンドで簡単に作成できます。 作成したPodはkubectl execコマンドを使って、bashシェルなどにログインすれば仮想マシンにアクセスする様に環境にログインして操作できます。 ただ、何も特別な設定をしていない状態でPodを作成すると、非永続のストレージしか利用できません。従ってPod内のコンテナーで再起動が走ってしまうとデータが消去されてしまいます。 たとえば次のようなYAMLファイルでPodを作成したとします。 kind: Pod apiVersion: v1 metadata: name: mywebpod spec: containers: - name: myfrontend image: nginx:lates

前回のエントリでKubernetesクラスタへSpinnakerをデプロイしました。 http://tech.virtualtech.jp/entry/2018/05/23/134107 Spinnakerのパイプラインを使用し、自動デプロイ環境を作成してみます。 筆者： コムシス情報システム株式会社　山本 聡 自動デプロイの全体図 自動デプロイ環境を行うにあたって、どういったデプロイの構造を実装するかを考えます。 開発環境と本番環境の2環境に対するデプロイを実施する。 開発環境はデプロイ対象物であるコンテナイメージの作成を検知後、自動的にデプロイする。デプロイされた環境は最新のものしか維持を行わない。 本番環境は開発環境での動作実績を元に人間がデプロイの可否判断する。 デプロイが承認された場合は開発環境で動作したイメージを本番環境へデプロイする。デプロイされた環境は古いものも維持する。

Kubernetesはコンテナアプリケーションのオーケストレーターです。 yamlによるサービス構築がkubectlコマンドで実行できますが、 さらに自動化されたデプロイ環境が欲しくなってくるのではないでしょうか。 そこで前回構築したKubernetesにContinuous Delivery Platformである 「Spinnaker」を動作させ、パイプラインによる自動デプロイを行いました。 筆者： コムシス情報システム株式会社　山本 聡（やまもと さとる） Kubernetesクラスタ環境の用意 まずはKubernetesクラスタを用意します。 以前当ブログにおいてJUJU+MAASでの環境構築を行っていますので、以下のエントリーを参考ください。 http://tech.virtualtech.jp/entry/2018/03/29/104216 Kubernetes永続ボリューム設

最近のGPU性能は著しく向上しており、GPUのグラフィック処理以外での利用(GPGPU)が増えてきています。とくにディープラーニングやデータマイニングなど、人工知能分野での利用が大きな注目を集めております。 KVM仮想マシン上でGPUを利用する方法の一つとしてPCIパススルーを利用する方法があります。ここではUbuntu 16.04でKVMの構築方法と仮想マシンでUbuntu 16.04の環境を作成方法までを紹介いたします。 前提条件 KVMホストとなるサーバーへUbuntu 16.04 Serverと仮想マシンマネージャーをインストールしておいて下さい。仮想マシンマネージャのインストールは別のマシンでも構いません。仮想マシンマネージャの詳細については以下のサイトを参照して下さい。 Virtual Machine Manager Home (本家サイト) Virtual Machine M

久しぶりにサーバーネタは、HDDトレイのパチモン（偽造品）を買って試すお話です。はじめに言うとトレイは一応使えましたが、言わずもがな使用は自己責任となります。 背景 長らく弊社の検証サーバー機材として活躍してきたHP ProLiant G6世代のサーバーが、iLO2のJava Appletリモートコンソールが使用不能になるなどしてOSやブラウザの進歩に追いつけなくなり、リプレースの対象になってきました。使う分にはスペック的に悪くないのでやや惜しいですね。現在は、代わりになるサーバーとして同じくHPEサーバーのGen8・Gen9世代や、Dell R620をオークションで調達しています。 Gen8世代以降のサーバーではハードディスクのトレイ形状が変更になったため、サーバーのリプレースに合わせてディスクトレイもそれなりにたくさん必要になります。オークションの中古サーバーは大抵はディスクがついてお

2017年5月末にMAAS 2.2がリリースされたので、早速試してみました。 MAAS 2.2 リリースノート Canonical Ubuntu MAAS 2.2は現在MAAS Stable PPAで公開されており、Ubuntu 16.04.x Serverで利用するには次のようにリポジトリーを有効化する必要があります。 $ sudo add-apt-repository ppa:maas/stable $ sudo apt update $ sudo apt upgrade $ sudo apt install maas #All-in-Oneインストール インストール方法についてはドキュメントが公開されています。 MAAS 2.2では様々な機能改修、機能追加が行われていますが、特に便利だったのがPodsと言う新機能でqemu-kvmをサポートしたことが挙げられると思います。 Pod t

はじめまして 技術ブログでははじめまして。平(Twitter:@mana_cat)です。 サーバーエンジニア、クラウドエンジニア、フリーランスを経験して今年4月に入社しました。二人の子どもを保育園に預けて時短勤務で働いています。 趣味はカメラと自宅IoTです。今後ブログも更新していきますのでよろしくお願いします。 OpenStack 構築手順書 Mitaka版の本を書きました 入社してからの初仕事は、OpenStack Mitakaを検証しながら、構築手順書を執筆することでした。先日、無事校了しましたのでご報告致します。 4月時点ではOpenStack初心者でしたが、OpenStackを動かしていく内にその奥深さに気付き、楽しく構築することができました。 時にはOpenStackの機能面でハマるところもありましたが、社内のナレッジやノウハウを共有してもらい、周囲の協力のお陰で乗り越えること

前回はvSphere 6の変更点について取り上げました。今回は旧バージョンからのアップグレードについて書きたいと思います。 VMware ESXi(以降ESXi) 5.xからESXi 6.0へのアップグレードについては、公式マニュアルの「vSphere のアップグレード」ガイドにあるようにUpdate Managerを使う方法もありますが、ESXi 6.0のISOイメージを使ってアップグレードインストールするのが簡単です。こちらの手順で説明されている方法でバックアップを取った上でアップグレードを実施します。 【実行例】 PowerCLI> Connect-VIServer 172.17.14.10 -User user -Password pass （接続） PowerCLI> Get-VMHostFirmware -DestinationPath C:\backup （指定パ

昔なんとなく立てた社内GitLabが立ててからだいぶ経ったような気がしたので、アップデートしました。最近のGitLabはあの特徴的なアイコンがモダンな感じになって良いですね。 さて、前のバージョンが6.4.3という古めのバージョンで、昔の手順（Chef Soloかな）でインストールされたものだったため、debパッケージで簡単に導入できる最新バージョンに移行する手順がやや複雑でした。OSもUbuntu12.04と少し古めになっていたため、14.04で新規に作った環境に移していく方法にしました。 作業については、こちらの記事が大変参考になりました。ありがとうございました。 http://rythgs.co/archives/2015/10/31/switch-omnibus-gitlab/ ちょっと違うやり方もしたので、自分のメモがてらざっくりと書いておきます。 新サーバーにGitLab 7.

今朝ごろからTwitter上でDockerCraftなるものが話題のようです。Dockerがリリースした、Minecraft上でDockerコンテナのステータスが確認できるものだとか。 実は私、今までなんとなくDockerを避けてきたのですが、ネザーで天井の岩盤から床の岩盤までぶちぬいてゾンビピッグマントラップタワーを建設している程度にはMinecraft好きですので、これはDocker入門せざるを得ません。早速、Docker入門を兼ねて動かしてみました。 Docker環境の用意 社内にある普段使い用のOpenStackにUbuntu14.04のインスタンスをさくっと立て、ドキュメントを参照しながらDockerをインストールしました。 https://docs.docker.com/v1.8/installation/ubuntulinux/ 一般ユーザーでdockerコマンドを実行できる

先日、Dockerの検証機材としてHP Moonshot 1500とProLiant m300 Server Cartridge、ProLiant m710 Server Cartridgeをお借りしてDockerとKVMの性能比較などいろいろ行いました。 お借りする期間を延長していただけたので、もう少し触ってみることにしました。 DockerコンテナーをHPサーバーで利用しているユーザーの多くは、一台のサーバーあたりおおよそ1000のコンテナーを動かすのが一般的なんだそうです。そこで実際ProLiant m300 Server Cartridge（以降m300）でDockerを動かし、どれくらいまでコンテナーを動かせるかを検証してみました。ちなみにDockerホストのOSはメインの検証で使ったRed Hat Enterprise Linux Server release 7.0 (Mai

SSHへの接続は秘密鍵・公開鍵認証を設定して行うのが基本ですが、万が一秘密鍵が盗まれてしまうと、パスフレーズでしか守られていない秘密鍵では総当たり攻撃で第三者が不正にサーバーに接続できてしまうことになります。 この問題に対応するために、SSHサーバーに2要素認証を設定し、秘密鍵・公開鍵暗号ともう1つの認証方法を組み合わせて安全性を高めることにします。もう1つの認証方法には、OATH(Initiative for Open Authentication)に対応した「Google Authenticator」を使ったワンタイムパスワード（OTP）認証を組み合わせてみます。 Google AuthenticatorはiOS版、Android版のOTP生成用アプリケーションが用意されているので、手軽に使うことができます。 また、Google Authenticatorはオープンソースとして公開され

ここ最近（G6世代以降）のHP ProLiantサーバーでは、各種テストや初期化などのいわゆるPOST時間がかかるようになり、2分前後になっています。G5世代（DL380 G5のデフォルト設定で計測）が1分前後で完了していたことを考えると、約2倍というのはちょっと辛いです。本番環境など、基本的に動かしっぱなしの環境では問題になりませんが、検証環境では再起動が多く発生する場合があるため、待つのが退屈になります。 そこで、RBSU（BIOSメニューのHPサーバーでの呼称）などの設定を変更して、起動時間の短縮ができるか試してみることにしました。サーバーにはHP ProLiant MicroServer Gen8サーバーを使用しました。 素の状態 素の状態のBIOS起動時間は2分3秒ほどでした。長いです、長い。 Power On Logoオプションを無効化 まずはグラフィカルなBIOS画面を表示す

最近になって、ようやっとVMware ESXi 5.0を使った検証作業が増え始めました。私が検証を担当しているわけではないのですが、サーバーの準備や設定のアドバイスなど補佐的なところをしている状況です。 さて、今作業中の検証環境で大容量のストレージが必要とのことで、iSCSIストレージの準備をしたのですが、設定した後からブートが極端に遅くなったり、iSCSIの設定をしても反応が返ってこなくなったりするようになりました。調べると、次のような記事がナレッジベースにあがっていて、当てはまっているかも知れない、ということでアップデートすることにしました。 ESXi 5.x boot delays when configured for Software iSCSI この問題にあわせて、ZIP形式のパッチと、パッチ済のISOイメージ（こちらは有償ライセンスを所持しているユーザーのみ）が配布されていま

ESXi単体を大体触ってみたところで、次はvCenter Serverのインストール・検証です。ZIP版を展開してまず目についたのが「vSphere-WebClient」と言うディレクトリ。これはすごく面白そうだったので、早速試してみました。 （ちなみに、ホストキャッシュのレポートがまだですが、とりあえず動作しました。） (大まかに)vSphere Web Clientが使えるようになるまでの流れ 次のような手順で、vSphere Web Clientが使用可能となります。 vCenter Serverをインストール vSphere Clientをインストール vSphere Clientにログインして、データセンタとホストの追加を行う vSphere Web Clientをインストール vSphere Admininstration Applicationで、vCenter Server

VMware vSphere 5がいよいよリリースされて、ESXi 5も数日前からダウンロードできるようになりました。私も早速入手して、ちょっとずつ触っているところです。かるく触ってみた感じでは、インストール時にキーボードやパスワードを設定できるようになったりしていますが、基本的にはESXi 4とほぼ変わりない雰囲気でした。 さて、ESXi 5では「ホストキャッシュ」と言う機能が追加されて、SSDをVMのメモリのスワップ置き場にすることで、メモリスワップ時の速度低下を低減させる、と言うもののようです。まずはホストキャッシュの追加までできましたので、こちらの手順をご紹介します。 検証に使用しているサーバーはHP ProLiant DL360 G6です。余談ですが、例によって数週間前にヤフオクで入手された出物です。ストレージ構成は次の通り。おなじみのSmartArray P410iで構成されて

Samba 3.6.0が8月9日にリリース[1]されました。 リリースノート[2]をみると、今回のバージョンは初めてSMB2をフルサポートしたバージョンで、早速使ってみた人の話によると、「ファイルのアップロードのパフォーマンスがかなり上がって感動もの」とのこと。 「これは使ってみるしかない」と思い立ち、新しい物大好きな私は早速テストサーバーを立てて試してみることにしました。なお、テストサーバーはUbuntu Server 11.04のKVM環境上で動かしました。実機やXen環境上で同じテストを行うともう少し良い結果が出るかもしれません。 現在、Samba 3.6.0を通常の方法で利用できるディストリビューションはないため、外部リポジトリのwingリポジトリ[3]を使って、CentOS 5.6にSamba 3.6.0をインストールすることにしました。 wingリポジトリの設定をして、いざSa