TECH BLOG: 2026

2026年6月30日火曜日

GitLab と GitLab Runner を連携させて CI/CD っぽいことをしてみるその３

今回は Gitlab Runner と連携する GitLab のプロジェクトを作成します。
管理者で GitLab にログインします。

プロジェクトを作成するには、プロジェクトが所属するグループが必要になるのでそちらをまず作ります。
「グループ」を表示して「新しいグループ」をクリックします。

「グループを作成」をクリックします。

「グループ名」を入力して画面下の「グループを作成」をクリックします。

グループが作成されるので「管理者」ボタンで戻ります。

「プロジェクト」を表示し「新規プロジェクト」をクリックします。

「空のプロジェクトの作成」をクリックします。

「プロジェクト名」を入力し、「グループまたはネームスペースを選択」で作成したグループを選び「プロジェクトを作成」をクリックします。

プロジェクトが作成されます。

このプロジェクトに対して操作ができるか確認してみます。
今回私は「Visual Studio Code」を使用するので、コードを表示してHTTPでクローンを行います。
リポジトリを作成したら「push-test.txt」を作成し中身は何でもいいので書いておきます。

内容を保存したら、対象のファイルをステージしてコミットしてプッシュ(変更の同期)します。

プロジェクトにファイルができていることを確認します。

これで GitLab Runner と連携する準備が整いました。

次回はこのプロジェクトに GitLab Runner を登録してみたいと思います。

2026年5月29日金曜日

GitLab と GitLab Runner を連携させて CI/CD っぽいことをしてみるその２

今回は、前回に続いて GitLab Runner を構築していきます。
土台として利用するのは GitLab と同様に Ubuntu です。
まず Ubuntu にログインして、root になります。

sudo su -

GitLab Runner のコマンドをダウンロード

sudo curl -L --output /usr/local/bin/gitlab-runner "https://s3.dualstack.us-east-1.amazonaws.com/gitlab-runner-downloads/latest/binaries/gitlab-runner-linux-amd64"

ファイルが指定した場所に置かれているか確認

ls /usr/local/bin/gitlab-runner
/usr/local/bin/gitlab-runner

実行権限の付与

chmod +x /usr/local/bin/gitlab-runner

GitLab Runner 用のユーザーを追加

useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

GitLab Runner のインストール

gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

連携する GitLab の証明書の格納先を作成

mkdir -p /etc/gitlab-runner/certs

※ここで、GitLab の証明書を GitLab Runner に転送するため一旦 GitLab にログインします。　

scp /etc/gitlab/ssl/demo-gitlab.crt ubuntu@GitLab RunnerのIP:/tmp/

GitLab Runner に戻ります。
オーナーとパーミッションを変えておきます（やらなくても大丈夫かもしれないですが試してないです）

cd /tmp/

オーナーを変更します。

chwon  root:root demo-gitlab.crt

パーミッションを変更します。

chmod 644 /tmp/demo-gitlab.crt

GitLab Runner は /etc/gitlab-runner/certs/ に配置された証明書を確認しますが、その際にどの証明書を使うのかをアクセス先の FQDN もしくは IPアドレスで確認します。
そのため、今回は転送した証明書をファイル名をGitLabのFQDNに変換して配置します。

mv /tmp/demo-gitlab.crt /etc/gitlab-runner/certs/GitLabのFQDN.crt

また OS 全体の信頼する証明書リストにこの証明書を追加します。

cp /etc/gitlab-runner/certs/GitLabのFQDN.crt /usr/local/share/ca-certificates/GitLabのFQDN.crt

証明書リストを更新します。

update-ca-certificates

以下のように『1 added,』と表示されればリストに1つ証明書が加わったことになります。

Updating certificates in /etc/ssl/certs...
rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL
1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

証明書を読み込むために GitLab Runner を再起動します。

gitlab-runner restart

これで GitLab と GitLab Runner の連携を行う準備ができました。
次回は、GitLab で GitLab Runner と連携するプロジェクトを作成してみようと思います。

2026年4月30日木曜日

GitLab と GitLab Runner を連携させて CI/CD っぽいことをしてみるその１

今回から、GitLab と GitLab Runner を構築し連携させて、GitLab のプロジェクトにあるファイルを更新をトリガーに GitLab Runner を動かして何かさせてみようと思います。

参考：https://docs.gitlab.com/ja-jp/install/package/ubuntu/?tab=Community+Edition

環境
OS：Ubuntu 24.04.2
DNSを利用して名前解決可能な状態

まず、作成済みの Ubuntu を使って GitLab のコミュニティエディション（CE）構築を行います。
SSH等でログインしてください。

権限などが必要になるので root になります。

sudo su -

インストールに必要なリポジトリの追加を行います。

curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

gitlabをhttpsで利用したいので、自己証明書を用意します。
自己証明書用のディレクトリ作成

mkdir -p /etc/gitlab/ssl

権限を変更します。

chmod 755 /etc/gitlab/ssl

事故証明書を作成します。

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/gitlab/ssl/demo-gitlab.key \
  -out /etc/gitlab/ssl/demo-gitlab.crt \
  -subj "/CN=" \
  -addext "subjectAltName = DNS:,"

聞かれる質問に対しては Common Name だけgitlabサーバーのFQDNを入れます。
この証明書を読み込んでもらえるように通常はインストール処理の中で作られる設定ファイルを先に作って証明書を指定します。

ディレクトリの作成

mkdir -p /etc/gitlab

ファイルの作成

touch /etc/gitlab/gitlab.rb

権限の変更

chmod 600 /etc/gitlab/gitlab.rb

作成した gitlab.rb に以下の内容を記入します

# URLを https に変更
external_url 'https://'

# Let's Encryptは使わないので false
letsencrypt['enable'] = false

# 証明書のパスを明示的に指定
nginx['ssl_certificate'] = "/etc/gitlab/ssl/demo-gitlab.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/demo-gitlab.key"

インストールを実行します。

apt install gitlab-ce

GitLabにログインするために必要な root のパスワードを確認します。
1日くらいでファイルが削除されるのでさっさとログインして初期パスワードを変更しましょう。

cat /etc/gitlab/initial_root_password

パスワードが確認出来たらログインします。

日本語化するため右上のアイコンをクリックし「Preferences」を選択します。

右側のスクロールバーを下に下げ「Localization」の「Lunguage」から日本語を選びます。

一番下の「Save changes」をクリックして設定を保存します。

忘れずにパスワードも任意のものを設定しておきましょう。

因みに、アップデートの通知が毎回出てきて煩わしいときがあると思いますが、その場合はここのチェックを外しましょう。

「管理者」ボタンがあるのでそれを押して管理者モードになり「設定」の「メトリックスとプロファイリング」から「使用状況の統計」をひらくとあります。
次回はこの GitLab と連携する GitLab Runner の構築を行おうと思います。

2026年3月31日火曜日

やってみよう Terrafrom で自動作成その４複数のリソースを一度に作成してみる

今回は、vSphere を使ってネットワークやフォルダ等の複数のリソースを一度に作成してみようと思います。

マニュアルはこちらです
https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs

リソースプール、フォルダ、ネットワークを作成してそれを利用する仮想マシンを展開しようと思います。
作業前の状態は以下です。

vSphere 側の準備
仮想マシン展開用のテンプレートになる仮想マシンを用意します。
今回はこのシリーズの「その２」で使用したUbuntuを使用したいと思います。

では、今回もこのTerraform実行ののディレクトリを作成し、そこに作成済みのログイン用のtfファイルをコピーしてください。
今回ですが、各リソース毎にtfファイルを作成して管理しやすくしようと思います。
そのため、共通で使う既存リソースを記載したdata.tfを用意し参照するようにします。

data.tf

# データセンターの取得
data "vsphere_datacenter" "dc" {
  name = "DC01"
}

# データストアの取得
data "vsphere_datastore" "datastore" {
  name          = "nfs01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

# クラスタの取得
data "vsphere_compute_cluster" "cluster" {
  name          = "CL01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

# テンプレートVMの取得
data "vsphere_virtual_machine" "template" {
  name          = "ubuntu-tmp"
  datacenter_id = data.vsphere_datacenter.dc.id
}

# vCenter上の分散スイッチの取得
data "vsphere_distributed_virtual_switch" "dvs" {
  name          = "DSwitch" 
  datacenter_id = data.vsphere_datacenter.dc.id
}

では、各リソース毎のtfファイルを作成していきましょう
・リソースプールのtfファイ名：resource_pool.tf
・フォルダのtfファイ名：vm_folder.tf
・ネットワークのtfファイ名：vm_network.tf
・仮想マシンのtfファイ名：test_vm04.tf

resource_pool.tf

resource "vsphere_resource_pool" "rp" {
  name                    = "Terraform-rp"
  parent_resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  
  # CPU/メモリのリソース設定（必要に応じて変更可能。デフォルトは制限なし）
  cpu_share_level    = "normal"
  memory_share_level = "normal"
}

vm_folder.tf

resource "vsphere_folder" "vm_folder" {
  path          = "Terraform-vm"
  type          = "vm"
  datacenter_id = data.vsphere_datacenter.dc.id
}

vm_network.tf

resource "vsphere_distributed_port_group" "pg" {
  name                            = "Terraform-vm-nw"
  distributed_virtual_switch_uuid = data.vsphere_distributed_virtual_switch.dvs.id

  # VLAN ID 
  vlan_id = 100
}

test_vm04.tf

resource "vsphere_virtual_machine" "vm" {
  name             = "test-vm-04"
  
  # 作成したリソースプール "Terraform-rp" を指定
  resource_pool_id = vsphere_resource_pool.rp.id
  
  # 作成したフォルダ "Terraform-vm" を指定
  folder           = vsphere_folder.vm_folder.path
  
  datastore_id     = data.vsphere_datastore.datastore.id

  num_cpus = 2
  memory   = 2048
  guest_id = data.vsphere_virtual_machine.template.guest_id
  firmware = data.vsphere_virtual_machine.template.firmware

  wait_for_guest_net_timeout = 0 #ネットワーク設定をしていないので確認をキャンセル

  network_interface {
    # 作成した分散ポートグループ "Terraform-vm-nw" を指定
    network_id   = vsphere_distributed_port_group.pg.id
    adapter_type = data.vsphere_virtual_machine.template.network_interface_types[0]
  }

  disk {
    label            = "disk0"
    size             = data.vsphere_virtual_machine.template.disks.0.size
    eagerly_scrub    = false
    thin_provisioned = true
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.template.id
    linked_clone  = true    
  }
}

実際に実行してみます。

terraform init
terraform plan
terraform apply

以下のように各リソースが作成されていることが確認できたので成功です。

この様に、各tfファイルを揃えておくと terraform apply で一度に作ってくれます。
ちなみ、terraform destroy すると一発で全部消えてしまうのでその点はご注意ください。

2026年2月27日金曜日

やってみよう Terrafrom で自動作成その３仮想マシンの作成とゲストOSのカスタマイズ（Linux）

今回は、vSphere を使って Ubuntu の仮想マシン展開時に、ゲストOSをカスタマイズする方法についてやっていこうと思います。

マニュアルはこちらです
https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs

vSphere 側の準備
Terrafrom を実行する前に、展開する仮想マシンの元になるテンプレートを作成する必要があります。
今回は、前回同様に仮想マシンを作成してゲストOSに Ubuntu をインストールしたものを用意しました。
仮想マシンの展開にかかる時間を短くするためにリンククローンを使用したいので、スナップショットを1つだけ作成しておきます。

ここまでは前回と同じですが、Terrafromが仮想マシンを展開する際にゲストOSのカスタマイズを行うには、あらかじめ Cloud-init を有効にしておく必要があります。
Ubuntu の場合デフォルトでインストールされているので以下のコマンドを実行してから仮想マシンを停止しておきます。

sudo cloud-init clean --logs

前回使った作業用の端末で、今回展開する仮想マシン用のディレクトリを作成します。
そこに、前回作成したログイン用のtfファイルをコピーします。
前回使った仮想マシン作成用のtfファイルもコピーして変更を加えていきたいと思います。

カスタマイズする内容は以下です。
・ホスト名：test-vm03
・IPアドレス：192.168.1.100
・ログイン用のユーザーを作成：ubuntu
・ログイン時にメッセージを出す：Welcome! This VM was configured by cloud-init

記載内容は以下になります。

create-test-vm03.tf

data "vsphere_datacenter" "dc" {
  name = "DC01"
}

data "vsphere_datastore" "datastore" {
  name          = "nfs01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_compute_cluster" "cluster" {
  name          = "CL01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_network" "network" {
  name          = "vm-DPortGroup"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_virtual_machine" "template" {
  name          = "ubuntu-cloud-init-tmp"
  datacenter_id = data.vsphere_datacenter.dc.id
}

resource "vsphere_virtual_machine" "vm" {
  name             = "test-vm-cloud-init"
  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id     = data.vsphere_datastore.datastore.id

  num_cpus = 2
  memory   = 2048
  guest_id = data.vsphere_virtual_machine.template.guest_id
  firmware = "efi"

  wait_for_guest_ip_timeout = 0

  network_interface {
    network_id   = data.vsphere_network.network.id
    adapter_type = data.vsphere_virtual_machine.template.network_interface_types[0]
  }

  disk {
    label            = "disk0"
    size             = data.vsphere_virtual_machine.template.disks.0.size
    eagerly_scrub    = false
    thin_provisioned = true
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.template.id
    linked_clone = true

#ここから先がOSのカスタマイズ内容になります
    customize {
      linux_options {
        host_name = "test-vm03"
        domain    = "snt-demo.lab"
      }

      network_interface {
        ipv4_address = "192.168.1.100"
        ipv4_netmask = 24
      }

      ipv4_gateway = "192.168.1.1"
    }
  }

  extra_config = {
    "guestinfo.userdata" = base64encode(<<EOT
#cloud-config
hostname: cloudinit-vm01

# ファイル作成
write_files:
  - path: /etc/motd
    permissions: '0644'
    content: |
      *****************************************
      Welcome! This VM was configured by cloud-init
      *****************************************

# ubuntuユーザーにパスワードを設定
users:
  - name: ubuntu
    plain_text_passwd: "Vmware1!"
    lock_passwd: false
    sudo: ["ALL=(ALL) NOPASSWD:ALL"]
    groups: [adm, dialout, cdrom, floppy, sudo, audio, dip, video, plugdev, netdev, lxd]
    shell: /bin/bash
ssh_pwauth: True

# 起動時に一度だけ実行されるコマンドを利用してrootのホームにテキストを残す
runcmd:
  - echo "Hello from cloud-init at $(date)" >> /root/cloud-init.log
EOT
    )
    "guestinfo.userdata.encoding" = "base64"
  }
}

実際に実行してみます。

terraform init
terraform plan
terraform apply

無事に仮想マシンができて処理が完了すると、IPアドレスとホスト名が vSphere Client から確認できます。

コンソールを開いて作成したユーザーでログインしメッセージが表示されるか確認します。

ちゃんとcloud-initが動作してゲストOSがカスタマイズできたことが確認できました。

2026年1月30日金曜日

やってみよう Terrafrom で自動作成その２仮想マシンの作成（Linux）

今回は、vSphere を使って Ubuntu の仮想マシンを展開する手順とゲストOSのカスタマイズ方法についてやっていこうと思います。

マニュアルはこちらです
https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs

vSphere 側の準備
Terrafrom を実行する前に、展開する仮想マシンの元になるテンプレートを作成する必要があります。
今回は、仮想マシンを作成してゲストOSに Ubuntu をインストールしたものを用意しました。
仮想マシンの展開にかかる時間を短くするためにリンククローンを使用したいので、スナップショットを1つだけ作成しておきます。

vSphere の構成としては以下のような感じで初期状態です。

tfファイルの作成。

1.Terrafrom を導入したマシンにログインします。
ここでは Ubuntu を使用しています。

2.作業用のディレクトリを作成します。

3.Terrafrom が何を使ってどの環境にログインできるようにするための tfファイルを作成します。
　1つの tfファイルに全部書いてもいいんですが、このログインに使う情報は別の仮想マシンを作りたいとき
　などに使いまわしができたほうが楽なので私はファイルを分けています。

このファイルに記載する内容は以下のようになります。

vSphere-login.tf

terraform {
  required_providers {
    vsphere = {
      source  = "hashicorp/vsphere"
      version = "~> 2.5"
    }
  }
}

provider "vsphere" {
  user           = "administrator@vsphere.local"
  password       = "Vmware1!Vmware1!"
  vsphere_server = "vc01.snt-demo.lab"

  allow_unverified_ssl = true
}

ここには2つの内容が書かれています。
以下の部分は、Terraformが各製品を扱う際に使用するプロバイダーというプラグインを、利用する製品に合わせて指定しています。
今回使う製品が vSphere なので hashicorp/vsphere になっています。

terraform {
  required_providers {
    vsphere = {
      source  = "hashicorp/vsphere"
      version = "~> 2.5"
    }
  }
}

以下の部分は vCenter へのログイン情報になります。
allow_unverified_ssl = true は自己証明書を使っているので、証明書の検証をスキップするために入れています。

provider "vsphere" {
  user           = "administrator@vsphere.local"
  password       = "Vmware1!Vmware1!"
  vsphere_server = "vc01.snt-demo.lab"

  allow_unverified_ssl = true
}

これで、Terrafrom が vSphere の製品を扱うことを理解して、接続先である vCenter とログインするためのアカウントおよびパスワードを知っている状態となります。

3.仮想マシン展開用のtfファイルの作成
　次に仮想マシンを展開する部分です。
　今回は仮想マシン以外のリソースは作成しません。

記載内容は以下になります。

create-test-vm01.tf

#使用するリソース（データセンター、クラスタ、データストア、ポートグループ、テンプレート用マシン）の指定
data "vsphere_datacenter" "dc" {
  name = "DC01"
}

data "vsphere_datastore" "datastore" {
  name          = "nfs01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_compute_cluster" "cluster" {
  name          = "CL01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_network" "network" {
  name          = "vm-DPortGroup"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_virtual_machine" "template" {
  name          = "ubuntu-tmp"
  datacenter_id = data.vsphere_datacenter.dc.id
}

#作成するリソースの内容
resource "vsphere_virtual_machine" "vm" {
  name             = "test-vm01"
  resource_pool_id = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id     = data.vsphere_datastore.datastore.id

  num_cpus = 2
  memory   = 2048
  guest_id = data.vsphere_virtual_machine.template.guest_id

  firmware = data.vsphere_virtual_machine.template.firmware

  network_interface {
    network_id   = data.vsphere_network.network.id
    adapter_type = data.vsphere_virtual_machine.template.network_interface_types[0]
  }
  
  # DHCPがない環境のためIPアドレス設定の確認を無視
  wait_for_guest_ip_timeout  = 0
  wait_for_guest_net_timeout = 0


  disk {
    label            = "disk0"
    size             = data.vsphere_virtual_machine.template.disks.0.size
    eagerly_scrub    = false
    io_reservation   = 1
    thin_provisioned = true
  }

  clone {
    template_uuid = data.vsphere_virtual_machine.template.id
    linked_clone  = true
  }
}

クローン元と同じでいい場合は data.vsphere_virtual_machine.template でテンプレートマシンを指定し、guest_id や firmware など参照させたい内容をくっつけるとテンプレートマシンの情報を使ってくれます。
テンプレートマシンとは異なる設定にしたい仮想マシン名やCPUやメモリといった値は直接書き込んで指定しています。

4.terrafromコマンドの実行　作成したtfファイルから仮想マシンの作成を行っていきます。 4-1.tfファイルを作成したディレクトリで初期化処理

以下のコマンドを実行します。

terraform init

4-2.tfファイルの確認

以下のコマンドを実行して apply 可能か確認します。

terraform plan

4-3.仮想マシンの展開

以下のコマンドを実行して仮想マシンを展開します。

terraform apply

実行していいか確認されるので yes を入力します。

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

成功すると以下のようにメッセージが出力されます

vsphere_virtual_machine.vm: Creating...
vsphere_virtual_machine.vm: Creation complete after 9s [id=421723e4-5f72-d210-9a4f-d503258be315]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

4-4.作成物の削除

作成したものを削除するときは以下のコマンドで削除します。

terraform destroy

こちらも実行していいか確認されるので yes を入力します。

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

vsphere_virtual_machine.vm: Destroying... [id=421723e4-5f72-d210-9a4f-d503258be315]
vsphere_virtual_machine.vm: Still destroying... [id=421723e4-5f72-d210-9a4f-d503258be315, 10s elapsed]
vsphere_virtual_machine.vm: Destruction complete after 14s

Destroy complete! Resources: 1 destroyed.

これで仮想マシンの作成と削除ができるようになりました。
次回は、作成する仮想マシンのゲストOSをカスタマイズする方法についてやっていきたいと思います。

2026年1月5日月曜日

VMware vSphere Foundation 9 の構築その４既存 vSphere 環境からの移行

前回までで新規での環境構築が終わりましたので、今回からは既存の vCenter と ESX のある環境を VVF にする手順についてやっていきたいと思います。
移行に入る前に以下の準備が必要です。

・DRS/HAを有効にする
・分散仮想スイッチにポートを移行している
・標準仮想スイッチは削除する

作業手順は以下の流れになります。

1. 既存の vCenter と ESX をアップグレードして 9 にする
2. VCF Installer で既存環境を選択し VVF 9 に構築する
3. VCF Operations でライセンス等の設定を行う

バージョンを9にする際、一般的には vCenter の ISOイメージから GUI を使用して 9 へアップグレードし、Lifecycle Manager を使って ESX のアップグレードになると思います。
その際ですが、Lifecycle Manager のデポで ESX のバージョンがうまくダウンロードできなくなっていたら以下の2つの KB で対処できるようです。

Resetting the VMware Update Manager Database
https://knowledge.broadcom.com/external/article/316581/resetting-vmware-update-manager-database.html
Authenticated Download Configuration Update Script
https://knowledge.broadcom.com/external/article/389276

私は、検証用の仮想マシンで作業していたので ESX 9 の IOSイメージを仮想マシンにマウントして、CDから起動しアップグレードをしました。
こっちのほうが楽なうえに早いので・・・

既存環境の vSphere 8 を VMware vSphere Foundation 9 に移行していきます。
VCF Installer にログインし『VMware Cloud Foundation』を選ぶところは新規構築と同じです。

既存コンポーネントで、『VMware vCenter Server』にチェックを入れます。

『全般情報』は 9.0.0.0 を設定します。

『VCF Operations』でサイズやパスワードの設定をします。

『vCenter』で既存の vCenter にログインするための認証情報を入力します。

『確認』で必要に応じて設定を確認します。

『検証とデプロイ』で検証に成功することを確認し、デプロイを実施します。
エラーが検出された場合は対応が必要ですが、警告については確認をクリックすればデプロイ可能となります。

処理が終わると、以下のようにパスワードの確認と VCF Operations へリンクが表示されます。

この後はVCF Operations の設定に入ります。
これは新規構築でも既存環境からの移行でも共通です。
一応、以前のブログで紹介しているのでそちらをご覧ください。
一番肝心なライセンス登録の部分については、ライセンスがないので説明を省いていますが・・・
VMware vSphere Foundation 9 の構築その５ VCF Operations の設定

登録: 投稿 (Atom)

TECH BLOG

このブログを検索

2026年6月30日火曜日

GitLab と GitLab Runner を連携させて CI/CD っぽいことをしてみるその３

2026年5月29日金曜日

GitLab と GitLab Runner を連携させて CI/CD っぽいことをしてみるその２

2026年4月30日木曜日

GitLab と GitLab Runner を連携させて CI/CD っぽいことをしてみるその１

2026年3月31日火曜日

やってみよう Terrafrom で自動作成その４複数のリソースを一度に作成してみる

2026年2月27日金曜日

やってみよう Terrafrom で自動作成その３仮想マシンの作成とゲストOSのカスタマイズ（Linux）

2026年1月30日金曜日

やってみよう Terrafrom で自動作成その２仮想マシンの作成（Linux）

2026年1月5日月曜日

VMware vSphere Foundation 9 の構築その４既存 vSphere 環境からの移行

ラベル

ページビューの合計

不正行為を報告

ブログアーカイブ

このブログを検索

2026年6月30日火曜日

2026年5月29日金曜日

2026年4月30日木曜日

2026年3月31日火曜日

2026年2月27日金曜日

2026年1月30日金曜日

2026年1月5日月曜日

ラベル

RSS

ページビューの合計

ブログ アーカイブ

ブログアーカイブ