ESXCLI Commands mit PowerCLI ausführen

Hallo,

aktuell ist die Hölle los, weshalb hier auch weniger neue Beiträge landen.

Das hier fande ich jetzt aber so lässig, dass ich mich trotzdem kurz hinhocken musste um etwas darüber zu schreiben.

Konkret geht es darum, ESXCLI Befehle via PowerCLI (also PowerShell) auf ESX-Hosts auszuführen. Wie geht das? Genau so:

$esxcli = Get-EsxCli -VMHost 1.1.1.1

$esxcli

====================
EsxCli: 1.1.1.1

   Elements:
   ---------
   esxcli
   fcoe
   hardware
   iscsi
   network
   software
   storage
   system
   vm

Wie kann man das verwenden?

$esxcli.network.nic.list()

Description : Intel Corporation 82545EM Gigabit Ethernet Controller (Copper)
Driver      : e1000
Duplex      : Full
Link        : Up
MACAddress  : 00:0c:29:80:f9:a0
MTU         : 1500
Name        : vmnic0
PCIDevice   : 0000:002:01.0
Speed       : 1000

Nachdem man mit ESXCLI ja bekanntlich nicht nur Abfragen starten kann, sondern auch Konfigurationen verändern kann.

Hier nur ein Beispiel. Zunächst holen wir mal die Config:

$esxcli.system.syslog.config.get()


DefaultNetworkRetryTimeout : 180
DefaultRotationSize        : 1024
DefaultRotations           : 8
LogOutput                  : /scratch/log
LogToUniqueSubdirectory    : false
RemoteHost                 : <none>

 

$esxcli.system.coredump.network.set

TypeNameOfValue     : VMware.VimAutomation.ViCore.Util10Ps.EsxCliExtensionMethod
OverloadDefinitions : {boolean set(boolean enable, string interfacename, string serveripv4, long serverport)}
MemberType          : CodeMethod
Value               : boolean set(boolean enable, string interfacename, string serveripv4, long serverport)
Name                : set
IsInstance          : True

Genau in dieser Reihenfolge können wir jetzt das „SET“ starten:

$esxcli.system.syslog.config.set(8,1024,180,"/scratch/log",$false,"1.1.1.2")
true

Kontrolle mit GET:

$esxcli.system.syslog.config.get()

DefaultNetworkRetryTimeout : 180
DefaultRotationSize        : 1024
DefaultRotations           : 8
LogOutput                  : /scratch/log
LogToUniqueSubdirectory    : false
RemoteHost                 : 1.1.1.2

Hier gibt es eine Übersicht über alle möglichen ESXCLI-Commands:

How to list all the PowerCLI ESXCLI commands

Durchaus nützlich in meinen Augen. Was meint ihr?

 

Bis demnächst.

 

Liebe Grüße

Falk

Netapp ONTAP9 ist da

Bei all dem Gerede über HyperConverged Storages, darf man traditionelle Storages nicht aus den Augen verlieren. 🙂

Heute landete eine Mail in meiner Inbox, dass ONTAP 9 verfügbar sein. Man munkelt ja schon seit einiger Zeit, dass dieses Release ein großer Wurf wird. Grund genug mal einen Blick auf die neuen Features zu werfen.

Netapp ONTAP9 ist da weiterlesen

VM Provisionierung im VSAN-Datastore

Im vorherigen Artikel haben wir den Aufbau und die Konfiguration eines VSANs durchleuchtet (mehr dazu hier). Jetzt soll es darum gehen, wie wir VMs in unseren VSAN Cluster provisionieren können.

Jetzt stellt sich die folgende Frage: Warum muss man jetzt darüber hier etwas schreiben? Wir erstellen schon seit Jahren VMs. Was ist daran so interessant?

VM Provisionierung im VSAN-Datastore weiterlesen

2-Node VSAN Cluster aufbauen

Meinem letzten Artikel über Hyperconverged Storages kann man ja durchaus entnehmen, dass ich doch ein kleiner Fan solcher Technologien bin. (Jürgen würde jetzt wahrscheinlich wieder sagen, ich sei generell leicht zu begeistern 😀 )). Egal.

Ich möchte in diesem Artikel die 2-Node Cluster Thematik etwas beleuchten.

2-Node VSAN Cluster aufbauen weiterlesen

Die Top IT Trends 2016 beschleunigen die Entwicklung zum Digitalen Unternehmen

Social, Mobile, Cloud, Analytik, Internet der Dinge und bimodale IT. Alles heiße Themen in unserer Branche, die IT-Funktionen und Teams in Unternehmen weltweit vor Herausforderungen stellen und doch so spannenden sind.

Ich glaube, all diese Trends und Technologien dienen einem größeren Zweck. Sie ermöglichen und unterstützen den Wandel von Organisationen in Richtung des digitalen Unternehmens. Mit anderen Worten, die Business Verantwortlichen nutzen IT Services um schneller und flexible auf Marktchancen (und Risiken) reagieren zu können und nutzen die Erfahrung jener Menschen mit denen es in Kontakt steht – Kunden, Mitarbeiter und Geschäftspartner.

Die digitale Transformation sollte ganz oben auf der Unternehmensagenda stehen, weil sie bereits jetzt die Wettbewerbslandschaft um uns herum neu gestaltet. Jene Unternehmen mit Mut zur Veränderung werden von dieser auch entsprechend mehr profitieren.

Welche Themen haben den größten Einfluss in der kürzest möglichen Zeit?

Die Top IT Trends 2016 beschleunigen die Entwicklung zum Digitalen Unternehmen weiterlesen

Hyperconverged Storages

Hat man bisher stets eine dedizierte Box benötigt, um ein Shared Storage zur Verfügung zu stellen, kommen vermehrt Rack-Server mit lokalen Disks ins Spiel. Genau diese Rackserver bilden untereinander ein „Distributed Storage“ und das ist die Idee hinter Hyperconverged Storages.

Aktuell ist der Markt überschaubar aber trotzdem breit gefächert. Es ist so, dass sich irgendwie je Anwendungsfall eine andere Lösung anbietet. Das liegt daran, dass sich die Lösungen in meinen Augen aktuell in verschiedene Richtungen entwickeln. Irgendwann werden sicher alle die gleichen Features bieten. Zumindest hat man das am traditionellen Storage-Markt beobachten können – inzwischen liefern ja sämtliche Hersteller ein ähnliches Featureset.

Hyperconverged Storages weiterlesen

VMware bringt neue Releases, darunter 6.0 Update 2

Überall hat man die letzten Tage Beträge zum Release von Update 2 sehen können. Neben Unmengen von Bugfixes, gibt es auch einige neue Features.

vSphere 6.0U2

  • Support für 25Gbit und 50Gbit Ethernet-Adapter
  • Ehemals als Fling bekannt, jetzt offiziell an Bord: Web Host Client (hier mehr dazu)
  • VAIO (vSphere API for IO filtering) Erweiterungen:
    • IPv6 Support
    • VMIOF 1.0 & 1.1 Support

Hier der Link zu den Release Notes.

VMware bringt neue Releases, darunter 6.0 Update 2 weiterlesen

Auf Abwegen – Wie Schatten IT entsteht

Folgende Situation:

Ein Mitarbeiter muss aufgrund von Termindruck am Wochenende arbeiten und benötigt einige Server um seine Arbeit zu vollenden.

Hand aufs Herz, wie gut funktioniert das mit der eigenen Infrastruktur? Beziehungsweise, wie weit kommt der Mitarbeiter?

Auf Abwegen – Wie Schatten IT entsteht weiterlesen

„Wir haben ein Problem“ – Wenn der Platz ausgeht …

Hin und wieder kommt es vor, dass Storage-Systeme „einfach“ volllaufen. Die Folgen laufen fast immer auf einen Systemstillstand hinaus. Nicht selten zu 100%.

Schuld ist meist einer dieser Punkte:

  • Hängengebliebene Snapshots
  • Überprovisionierte Storages – „Thin Provisioning“
  • Software

„Wir haben ein Problem“ – Wenn der Platz ausgeht … weiterlesen

Ein eigenes Docker Container-Repository

Der erste Container läuft. Wunderbar.

Was funktioniert gleich so super mit Containern? Scale-Out? Unsere Clouddays werden gut besucht und unsere CloudDaysWebApp könnte mehr Ressourcen vertragen. Docker Hosts hätten wir zu genüge, nur wie bringen wie unseren Container dorthin?

Wir müssten irgendwie unseren Container ins „Docker Hub“ bringen. Nein besser, wir bräuchten ein eigenes Repository, ähnlich wie „Docker Hub“. Da wir nicht die ersten sind, die genau sowas brauchen, gibt es das schon. 🙂 Es nennt sich „Registry“ und (wie sollte es anders sein?) kommt als fertiger Container aus dem Docker Hub (Link hier).

Das Prinzip ist folgendes: Wir „pushen“ unsere Container ins Repository und können sie nachher von diversen anderen Hosts „pullen“.

Unser Setup sieht wie folgt aus:

Docker-Registry

Die Kommunikation zwischen den Docker-Hosts und der Docker-Registry ist mittels TLS gesichert. Damit das möglich ist, benötigen wir SSL-Zertifikate. Für unseren kleinen internen Testaufbau sind selbstausgestellte völlig ausreichend. Die Zertifikate werden wir mit Volume-Mappings in den Container bringen. Dafür legen wir zunächst einen Ordner an:

mkdir –p /docker_volumes/registry/certs
cd /docker_volumes/registry/certs

Hier generieren wir jetzt unsere Zertifikate. Mit dem folgenden Befehl kann man eigene Zertifikate erstellen. Wichtig ist dabei der „common name“. Hier muss unser Servername eingetragen werden. In unserem Fall „didata„.

openssl req -new -newkey rsa:2048 -sha256 -nodes -x509 -keyout docker_registry.key -out docker_registry.crt

Generating a 2048 bit RSA private key
   ............................................................................................+++
.....................+++
writing new private key to 'docker_registry.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:AT
State or Province Name (full name) []:Tyrol
Locality Name (eg, city) [Default City]:Innsbruck
Organization Name (eg, company) [Default Company Ltd]:DiData
Organizational Unit Name (eg, section) []:Operations
Common Name (eg, your name or your server's hostname) []:didata
Email Address []:my.name@company.org

Jetzt können wir unseren Registry-Container holen. Dabei mappen wir Port 5000 gerade durch und reichen das Verzeichnis /docker_volumes/registry/certs als /certs in den Container durch.

docker run -d -p 5000:5000 --restart=always --name registry -v /docker_volumes/registry/certs/:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/docker_registry.crt -e REGISTRY_HTTP_TLS_KEY=/certs/docker_registry.key registry:2

Da wir self-signed Zertifikate verwenden, müssen wir allen beteiligten Hosts mitteilen, dass die von uns erstellten Zertifikate vertrauenswürdig sind. Hierfür muss zunächst der folgende Ordner angelegt werden:

/etc/docker/certs.d/*repo-dns-name*:5000

In unserem Fall folgender:

mkdir -p /etc/docker/certs.d/didata:5000

Hier legen wir jetzt das CRT-File ab und nennen es „ca.crt“, also:

cp /docker_volumes/registry/certs/ docker_registry.crt /etc/docker/certs.d/didata:5000/ca.crt

Da wir in unserem konkreten Fall auch keinen DNS-Server haben, behelfen wir uns noch mit einem /etc/hosts-Eintrag:

echo "192.168.1.100  didata" >> /etc/hosts

Wenn jetzt unser Container läuft (docker ps), können wir einen ersten Test starten.

Wir taggen unseren CloudDaysWebApp-Container entsprechend um. Dafür suchen wir zunächst die Image-ID unseres Containers:

[root@Docker-Host01 CloudDays]# docker images
REPOSITORY                   TAG                 IMAGE ID           CREATED             VIRTUAL SIZE
clouddayswebapp               latest             03d3c462af38       16 seconds ago     133.9 MB
…
nginx                         latest             407195ab8b07       5 weeks ago         133.8 MB

Und setzen den folgenden Tag:

Docker tag –t *Image-ID* *Repo-DNS-Name*:5000/*Containername*

Also in unserem Beispiel:

docker tag –t 03d3c462af38 didata:5000/clouddays

Mit “docker push” können wir jetzt unseren Container in unser Repository hochladen. In unserem Beispiel lautet der Befehl:

docker push didata:5000/clouddays

Wenn das erfolgreich angeschlossen wurde, kann auf jedem anderen Docker-Host der Container gestartet werden, wenn denn folgende Kriterien erfüllt sind:

  • Das SSL-Zertifikat ist vertrauenswürdig
  • Die Namensauflösung funktioniert
  • Docker ist installiert

Damit das alles auf Anhieb funktioniert, habe ich ein prepare-host.sh erstellt:

### Add Docker-Repo to YUM:
cat >/etc/yum.repos.d/docker.repo <<-EOF
[dockerrepo]
name=Docker Repository
baseurl=https://yum.dockerproject.org/repo/main/centos/7
enabled=1
gpgcheck=1
gpgkey=https://yum.dockerproject.org/gpg
EOF

### Install Docker:
yum -y install docker-engine

### Enable Docker:
systemctl enable docker.service

### Docker-Registry Config:
###### 1. Create Folder
###### 2. Place Cert for Registry Service
###### 3. Reload Docker
###### 4. Set Host-Entry "didata" (registry-service)
mkdir -p /etc/docker/certs.d/didata:5000

cat > /etc/docker/certs.d/didata:5000/ca.crt <<-EOF

-----BEGIN CERTIFICATE-----
<Bitte Zertifikat einfügen.> :-)
-----END CERTIFICATE-----
EOF

systemctl restart docker

echo "192.168.1.100  didata" >> /etc/hosts

Damit ist alles Relevante installiert und konfiguriert. Nachdem ich gestern jedoch schon entsprechend darauf angesprochen wurde … Mit Puppet oder Chef geht das natürlich auch ganz wunderbar. Dazu vielleicht mal zu einem späteren Zeitpunkt mehr. 🙂

Sind alle Voraussetzungen erfüllt, können wir auf unseren Docker-Hosts den Container pullen und starten. Tatsächlich braucht es das pull nicht als eigenen Schritt. Wir können direkt docker run verwenden. In unserem Beispiel:

docker run -d -p 80:80 –-name CloudDays didata:5000/clouddays

Wenn alles richtig konfiguriert wurde, wird der Container jetzt laufen. Kontrolle wie immer mit „docker ps“.

Macht man das jetzt in der Cloud und aktiviert einen Load-Balancer, hat man eine 1A Lastverteilung ohne großen Aufwand.

 

Wir haben jetzt also einen Container und ein Repository. Den Container können wir in diesem Setup beliebig oft auf beliebig vielen Hosts deployen. Der nächste Artikel wird auf die angekündigte BaaS-Demo eingehen. 🙂