OpenStack

z punktu widzenia

dewelopera i operatora

Paweł Suder

17.05.2018

GitHub

O mnie

Zajmuję się komputerami od kilku lat
Programowałem w C, Java, Python i Ruby
Zajmowałem się OpenStackiem jako chmurą prywatną
Pracowałem jako inżynier wsparcia klientów Cisco
Pracuję z OpenStackiem jako chmurą publiczną
Jeżdżę na motocyklu enduro i chodzę po górach

OpenStack

Moja historia

OpenStack - kiedyś

Konfederacja usług cloud Atmosphere
Obsługa prywatnych instalacji OpenStack
Instalacja z paczek dystrybucji Ubuntu
Brak zarządzania konfiguracją
Wersja OpenStacka: Havana lub Icehouse
Głównie obsługa operatorska clouda

W ramach projektu VPH-Share, w zespole DICE Cyfronet AGH, pracowaliśmy nad rozwiązaniem integrującym różne instalacje cloud

posiadaliśmy proste instalacje OpenStacka na kilku hostach
instalacja była oparta o paczki z dystrybucji Ubuntu
totalny brak automatyzacji instalacji czy konfiguracji
byliśmy typowymi użytkownikami OpenStacka, którzy potrzebowali clouda

Wersji OpenStacka nie pamiętam, ale najprawdopodobniej była to wersja Icehouse lub, wcześniejsza wersja, Havana
Pracowałem nad narzędziami do obsługi zadań związanych z obsługą clouda

jednym z narzędzi był serwis odpowiedzialny za wykonywanie zmian na węźle sieciowym do obsługi DNATa - ówczesne rozwiązania sieciowe OpenStacka, jakie mieliśmy wdrożone, nie obsługiwały tego
innym narzędziem była obsługa synchronizacji obrazów między instalacjami cloud

OpenStack - teraz

Chmura publiczna OVH na OpenStacku
Instalacja specyficzna dla OVH
Konfiguracja z wykorzystaniem Puppeta
Workflow pracy nad kodem podobny community
Upgrade OpenStacka z Juno do Newtona i wyższej

O OVH usłyszałem nim cloud stał się realny i popularny - głównie za sprawą usługi 60free - mój kierownik projektował tę usługę
O historii rozwoju clouda w OVH za chwilę
Instalacja jest specyficzna ze względu na zaszłości historyczne w OVH związane z obsługą serwerów dedykowanych
Konfiguracja instalacji wykonywana jest z wykorzystaniem Puppeta
Nad kodem OpenStacka pracujemy w podobny sposób, jak w community
Ze względu na przeszłość sieciową, zajmuję się w OpenStacku komponentami sieciowymi - wykonywałem instalację usługi load balancer opartą o rozwiązanie OVH
Obecnie intensywnie pracujemy nad opracowaniem, wykonaniem i przetestowaniem procedury aktualizacji kilku starszych regionów do nowszej, wspólnej dla całego instalacji, wersji Newton
Następnie planujemy wykonać mniej inwazyjny i skomplikowany upgrade do nowszej wersji OpenStacka, która jest jeszcze wspierana przez community OpenStacka

OpenStack

Historia

Cloud w latach 1977/1981/1993
Cloud jako produkt/usługa od 2000
Popularyzacja dzięki Amazon Elasitc Compute Cloud od 2006 - IaaS
Uruchomienie Google App Engine w 2008 - PaaS
OpenNebula w 2008 - private/hybrid-cloud open source platform
Uruchomienie Microsoft Azure w 2010 ogłoszonej w 2008
W 2010 rozpoczęcie prac nad OpenStackiem przez Rackspace i NASA
Założenie fundacji OpenStack w 2012

W 1977 symbol cloud używany był przez ARPANET do reprezentacji sieci rozpiętej między urządzeniami obliczeniowymi
W 1981 symbol cloud użyty został przez CSNET
W 1993 nazwa cloud użyta została do określenia platformy dla obliczeń rozproszonych.
Inne nazwy używane do nazywania systemów obliczeń rozproszonych to: grid, mesh, ..
Po 2000 cloud zaczął pojawiać się jako usługa/produkt
W 2006 Amazon uruchomił usługę Elastic Compute Cloud
W 2008 Google uruchomiło App Engine w wersji beta (pełne uruchomienie w 2012/13), OpenNebula została udostępniona, a Microsoft ogłosił, że będzie udostępniał Azure
W 2010 Microsoft uruchomiło Azure, a Rackspace i Nasa zaczęło prace nad OpenStackiem
Podobne do OpenStacka były projekty: CloudStack, Ganeti czy OpenNebula
W 2012 fundacja OpenStack została założona

Artykuły:

https://www.wired.com/1994/04/general-magic/
http://delivery.acm.org/10.1145/1730000/1721672/p50-armbrust.pdf
https://link.springer.com/content/pdf/10.1007%2Fs13174-010-0007-6.pdf
http://home.cse.ust.hk/~weiwa/teaching/Fall15-COMP6611B/reading_list/AboveTheClouds.pdf

Fundacja

OSF odpowiada za OpenStacka, KataContainers, Zuul oraz Edge
Fundacja OpenStack opiera się na trzech filarach: Board of Directors, Technical Committee, User Committee
SIG - Special Interest Groups aka working groups
Zasada czterech O: Open Source, Open Design, Open Development, Open Community

Fundacja OpenStacka odpowiedzialna jest za dostarczanie zasobów potrzebnych do rozwoju OpenStacka i innych projektów
W skład fundacji wchodzą także KataContainers, Zuul, Edge
OpenStack opiera się na trzech jednostkach: Board of Directors, Technical i User Committee.
Board odpowiedzialny jest za fundację - mało o niej wiem
Technical Committee odpowiedzialny za rozwój całości
User Committee za używanie OpenStacka - Public Cloud WG
SIG to grupy, które są używane do współpracy między deweloperami, operatorami oraz użytkownikami - np. Public Cloud WG
Działania OpenStacka opiera się na zasadzie czterech O
- We are committed to creating truly open source software that is usable and scalable
- We are committed to an open design process.
- We maintain a publicly available source code repository through the entire development process.
- One of our core goals is to maintain a healthy, vibrant developer and user community. Most decisions are made using a lazy consensus model.

Technical Committee

Pion odpowiedzialny za techniczne aspekty rozwoju OpenStacka
TC (członkowie i chairman), PTL, core reviewers, reviewers
Spotkania projektowe
Wybory do TC oraz na PTL
Nominacje na core reviewer
Project Team Guide

W ramach TC znajduje się to wszystko, co dotyczy projektów i ich rozwoju pod kątem technicznym (technical leading)
Wybory do TC są określone wg przepisów działania pionu TC
Do TC wybieranych jest 13 osób raz na 6 miesięcy. Spośród tych 13 osób jedna osoba wybierana jest na TC chairman.
W ramach każdego z projektów są: PTLs, core reviewers, zwyczajni reviewers, deweloperzy
Zespół powinninen posiadać osoby takie jak: PTL oraz core reviewers
PTLs wybierani są co 6 miesięcy, przy okazji nowego releasu OpenStacka - nie ma określonej maksymalnej ilości kadencji
Core reviewers nominowani są przy okazji wyborów PTL
Każdy z projektów ma swoje spotkania, określony sposób działania, a także repozytoria, miejsce na Launchpadzie, etc.
Co do wyborów na PTL czy core reviewers - określa to dokument Project Team Guide

Narzędzia i praca nad kodem

Komunikacja: głównie IRC i listy dyskusyjne
Narzędzia do pracy z kodem: Gerrit oraz Git (repozytoria na GitHub)
Tesowanie kodu: Unit tests, Tempest (integracyjne), RefStack (zgodności API), Grenade (upgrade)
Zgłaszanie bugów/featurów(RFE): Launchpad/StoryBoard
Dokumentacja: Specs oraz dokumentacja
Workflow: od mastera do releasów, review na Gerricie, testy na gates, więcej info

Większość zespołów używają IRCa oraz list dyskusyjnych do komunikacji
Kod trzymany w repozytoriach Gita, zaś review kodu wykonywane na Gerricie
Kod jest testowany: unit testy, tempesty, refstack tests, fullstack tests, grenade tests (upgrade)
Bugi czy nowe featury zgłaszane są przez otwarcie zgłoszenia (buga) na Launchpadzie lub StoryBoard
Dla buga wszystko odbywa się na Launchpadzie
Dla feature request - najpierw wykonany ma zostać RFE/specs, a dopiero później implementacja
Zmiany powinny być wykonywane dla mastera, a następnie być cherry-pickowane do wspieranych branchy
Zmiany są sprawdzane przez core revierów oraz inny reviewerów (każdy może robić review!)
Zmiany muszą przechodzić testy ;)
Jak wszystko jest okey, to zmiany automatycznie są merge'owane, ale nie cherry-pickowane (manualnie)
Oprócz specyfikacji, jest także zwykła dokumentacja, która dotyczy użytkowania czy zarządzania cloudem, itd.

Lifecycle

Community goals
Release jest co 6 miesięcy
Dwie lub trzy wersje RC przed final release
End-of-Life po roku/dwóch latach
Więcej info o wsparciu dla stabilnych wersji

Architektura

Wiele serwisów do obsługi różnych zasobów
Komunikacja oparta o HTTP lub kolejki - RabbitMQ
Backend oparty o bazę danych - MySQL/MariaDB oraz PostgresSQL
Najważniejsze projekty: Keystone, Nova, Neutron, Glance
Więcej na OpenStack Software Overview

Instalacja

Głównie na Ubuntu czy RedHat/CentOS
Standardowo instalacja z paczek dystrybucji systemu
Konfiguracja manulna (wg dokumentacji) lub z wykorzystaniem Puppeta albo Chefa
Inne sposoby instalacji i konfiguracji: Kolla, Helm lub przy pomocy Ansible
Inne mechanizmy: Fuel, TripleO

Instalacje OpenStacka wykonywane są głównie na Ubuntu, RedHacie lub CentOSie albo Suse
Standardowo wykonuje się instalację o paczki zbudowane na potrzeby dystrybucji - Ubuntu to CloudArchive, RedHat/CentOS - RDO
Dokumentacja dla operatorów podaje, jak manualnie skonfigurować OpenStacka
W ramach OpenStacka istnieją także projekty, które dot. sposobów instalacji i konfiguracji OpenStacka przy pomocy Puppeta, Chefa
Poza instalacją/konfiguracją, opracowywane są także narzędzia do wdrażania kolejnych węzłów, np. z wykorzystaniem playbooków Ansible
Całość instalacji można wykonać w oparciu o Kubernetesa dzięki Helm, Dockera dzięki Kolla, czy też wykorzystując OpenStack Fuel lub OpenStack TripleO (OpenStack on OpenStack)
Oprócz tego istnieją jeszcze inne mechanizmy instalacji i zarządzania cloudem, które są rozwiązaniami autorskim poszczególnych dostawców clouda opartego o OpenStacka, jak np. Mirantis

Wydarzenia i współpraca

OpenStack Summit i PTG - główne wydarzenia fundacji
OS Days, OS App Hackathon, Communit events - inne wydarzenia społeczności OpenStack
Stackalytics - statystyki dot. kodu i review
Różne modele biznesowe pracy z OpenStackiem

Inne

OpenStack w OVH

Historia

W 2012 rozpoczęto prace
- hubiC - usługa storage'u oparta o OpenStack Swift
- RunAbove - pierwszy Public Cloud oparty o OS
W 2014/15 uruchomiono Public Cloud w OVH
Od 2015 uruchamiano kolejne region PCI w OVH

Wybraliśmy OpenStacka, bo:

jest modularny
działa na serwisach
stoi za nim silne community
całość napisana jest w pythonie

Zaczęliśmy od wdrożenia OpenStacka na potrzeby Public Cloud Storage - usługi Keystone i Swift.
Następnie wdrożylismy OpenStacka na potrzeby Public Cloud Infrastructure, w ramach spin-offu RunAbove. Celem była wysoka wydajność za przystępną cenę.
Kiedy został osiągnięty pewien próg znajomości OpenStacka, został on wdrożony w ramach OVH jako Public Cloud.
Kilka znaczących elementów OpenStacka zostało zmienionych, jak np. zmiana sieciowych rozwiązań, aby wspierać publiczny adres IP na instancji.
Dodaliśmy własny monitoring (na potrzeby wewnętrzne i klienta).
Połączyliśmy PCI z systemem billingowym, który istniał w OVH.

Wdrożenie

Wdrożenie oparte o paczki z Ubuntu z manualnymi zmianami
Puppet do zarządzania konfiguracją
Konfiguracja Puppeta oparta o OpenStackowe i OVH moduły
Od uruchomienia usługi PCI zaczęto budować paczki - CI/CD
Od wersji Newton:
- zaadaptowano workflow do pracy nad kodem z OpenStack community
- zaczęto używać r10k do Puppeta
- rozdzielono kod OVH od kodu z upstreamu

Pierwsze wdrożenie bazowało na paczkach Ubuntu
Od samego początku używano Puppeta do konfiguracji OpenStacka
W trakcie rozwoju prac nad OpenStackiem, zaczęto dodawać specyficzne dla OVH moduły, które dotyczyły konfiguracji hostów, wewnętrznych systemów do monitoringu, itd.
Wraz z uruchomieniem usługi Public Cloud rozbudowano mechanizmy związane z pracą nad kodem OpenStack i na potrzeby wewnętrzne zaczęto budować paczki
Wraz z wdrożeniem wersji Newton w nowych regionach, zaadaptowano workflow OpenStacka do pracy nad kodem oraz zaczęto używać r10k do zarządzania modułami w Puppecie
Przy okazji, rozdzielono kod upstream od kodu OVH

Workflow pracy z kodem

DevStack, Dev Infra, Preprod, Prod
Unit Tests, Tempest i testy integracyjne
Unit testy i tempesty uruchamiane przy każdej zmianie
Testy integracyjne uruchomione na preprodzie
Dokumentacja ze specyfikacją dla nowych funkcji
Zmiany do mastera i cherry-picki do release'ów

Deweloperkę najczęściej wykonujemy na DevStacku, chyba, że task dot. buga na produkcji, wtedy jeśli jest to niemożliwe z DevStackiem, to próbujemy zrobić repro na dev infrze

Do testowania używamy unit testów, tempestów na DevStacku oraz wew. testów integracyjnych

Unit testy oraz tempesty uruchamiane są przy okazji publikacji zmian do review

Preprod jest środowiskiem podobnym do proda, na którym najpierw jest instalowana nowa paczka i uruchamiane są testy integracyjne

Umieszczenie paczki na produkcji wykonywane jest przez zespół RUN po stwierdzeniu, że preprod działa z nową paczką

Nowe featury, które nie będą wysyłane do upstreamu, wymagają wew. specsów, czyli dokumentów określających, co nowy feature ma robić - tak samo w upstreamie

Po zatwierdzeniu specsa można przystąpić do implementacji

Po wykonaniu implementacji w masterze, należy wykonać cherry-picki do releasów

Praca z upstreamem

Repozytoria z kodem wewnętrznie hostowane
Zmiany do upstreamu wysyłane zgodnie z community workflow
Zmiany z upstreamu pobierane i syncowane z lokalnymi repozytoriami
Sync z upstreamem wykonywany manualnie
Kod Novy oraz Neutrona rozdzielony od kodu z upstreamu

Narzędzia

Gerrit do wykonywania review
Jenkins do uruchamiania
- testów jednostkowych dla review
- cyklicznych testów integracyjnych
- innych cyklicznych zadań
Puppet do konfiguracji
Wewnętrzne narzędzia do zarządzania i monitorowania serwerów dedykowanych

Naszymi głównymi narzędziami są Gerrit oraz Jenkins
Cokolwiek co można zmienić i znajduje się w ramach kompetencji naszego zespołu, powinno przechodzić przez review - specsy, zmiany w kodzie, zmiany w devstacku, w budowaniu paczek, itd.
Zmiany w kodzie wymagają działających poprawnie testów
Puppet używany jest do uruchamiana DevInfry, Preproda i Proda - jego utrzymaniem zajmuje się w dużej mierze zespół odpowiedzialny za utrzymanie produkcji
Do uruchamiania DevInfry, itd. korzystamy z narzędzi, które powstały wcześniej w OVH i były wykorzystywane do obsługi serwerów dedykowanych
Wewnętrznie posługujemy się jeszcze narzędziami do zbierania logów z hostów, monitoringu hostów, zarządzania ich instalacją, itd.
Oprócz tych narzędzi, posługujemy się JIRĄ, Confluencem oraz Stashem - do logowania pracy, dokumentacji oraz utrzymania repozytoriów Gita

Usługa w OVH

Dysk root instancji bazujący na SSD:
- plus: wydajność
- minusy: utrudniona migracja, nie da się szybko przywrócić VMki po wyłączeniu hosta
Dodatkowe dyski (wolumeny) umieszczone są na Cephie
Sieć publiczna chroniona jest systemem Anti-DDoS

OpenStack

Przykład użycia

Przykład na GitHubie

Horizon

W projekcie wymagany jest klucz publiczny SSH

Horizon

Dodanie serwera można wykonać przez menu projektu

Horizon

Uruchomienie instancji

Tworząc instację, należy wybrać region, obraz bazowy i typ serwera. Na potrzeby prezentacji użyłem Ubuntu 16.04, z odmianą sandbox, w Warszawie, o nazwie web-1.

W OVH, przy uruchomieniu instancji z OpenStack API, określany jest sposób naliczania opłat na godzinowy.

Czym jest region?

jest to DC(centrum danych), w ramach którego znajdują się fizyczne maszyny, na których uruchamiane są instancje, czyli serwery
w panelu klienta widoczne są instancje ze wszystkich regionów

Czym jest obraz bazowy?

jest to dysk, z którego jest uruchamiana instancja
dla każdej z instancji, tworzony jest oddzielny dysk podstawowy, w oparciu o ten obraz
możliwe jest wykonanie własnych obrazów, wykonując snapshoty działającej instancji

Czym jest typ serwera?

jest to definicja zasobów, z którymi uruchamiana jest instancja
określa przede wszystkim ilość rdzeni, wielkość pamięci operacyjnej oraz rozmiar podstawowego dysku instancji

Dodatkowo, przy tworzeniu instancji możliwe jest określenie liczby instancji do uruchomienia, podanie skryptu do konfiguracji instancji (wykonywanego po uruchomieniu systemu) czy określenie sieci prywatnej, do jakiej ma zostać instancja podłączona.

Przy uruchomieniu instancji użyjemy skryptu post-install, by móc skorzystać później z skryptów Ansible.

#!/usr/bin/env bash

sudo apt update
sudo apt install -y build-essential python python-dev python-pip python-setuptools

O używaniu sieci prywatnej powiem przy okazji vRacka.

Horizon

Tworzenie instancji

Instancja

Oto przykład, na którym widać, że na nowo utworzonej instancji, jest określona liczba procesorów, ilości pamięci operacyjnej oraz jest określonej wielkości dysk twardy.

lscpu | grep -e Architecture -e CPU -e Thread -e Core
free -m
lsblk
ip addr show ens3

CLI API

Cloudem można także zarządzać API.

Dostęp do OpenStack API daje możliwość korzystania z narzędzi i skryptów do automatyzacji działania instalacji opartej na cloudzie, jak na przykład Ansible, Terraform, itd.
Nasza instalacja posiada obecnie dwie wersje API: Juno oraz Newton. Pracujemy nad posiadaniem tylko jednej wersji - Newton.

Oto przykład, na którym jest widoczne, jak można uruchomić instancję z poziomu OpenStack API. Po chwili można zalogować się na instancję przez SSH.

source ~/Spaces/GitHub/openstack-playground/openrc-demo-waw1.sh
nova list --fields name,status
nova keypair-list
nova keypair-add --pub-key ~/.ssh/id_rsa.pub psuder_desktop
nova keypair-list
nova boot --flavor s1-4 --image "Ubuntu 16.04" --nic net-name=Ext-Net --key-name psuder_desktop testing
nova list --fields name,status
nova list --fields name,status
nova list --fields name,networks
ssh ubuntu@54.37.131.86
uptime
nova list --fields name
nova delete testing
nova list --fields name

Sieci w OVH OpenStack

Publiczna i prywatna vRack

Sieć publiczna w OVH

Publiczne adresy IP skonfigurowane bezpośrednio na instancji
Brak ruchu L2 na interfejsie instancji
Możliwość korzystania z adresów IP FailOver
Brak klasycznego węzła sieciowego

➜  ~ nova list --fields name,status,networks
+--------------------------------------+-------+--------+-----------------------------------------------+
| ID                                   | Name  | Status | Networks                                      |
+--------------------------------------+-------+--------+-----------------------------------------------+
| a8337ef7-693b-4f8f-a90c-b5d4ed087528 | web-1 | ACTIVE | Ext-Net=54.38.136.26, 2001:41d0:601:2000::26c |
+--------------------------------------+-------+--------+-----------------------------------------------+

ubuntu@web-1:~$ ip addr show ens3
2: ens3:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:5b:71:db brd ff:ff:ff:ff:ff:ff
    inet 54.38.136.26/32 brd 54.38.136.26 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fe5b:71db/64 scope link
       valid_lft forever preferred_lft forever
ubuntu@web-1:~$ ip route
default via 54.38.136.1 dev ens3
54.38.136.1 dev ens3  scope link

Sieć prywatna w OVH - vRack

Prywatne połączenie wszystkich serwerowni OVH na świecie

Sieć prywatna w OVH - vRack

vRack pozwala na odizolowanie najważniejszych serwerów w ramach prywatnej sieci VLAN

Sieć prywatna w OVH - vRack

Możliwe połączenie Public Cloud z serwerami dedykowanymi

Sieć prywatna w OVH - vRack

Dodawanie sieci prywatnej vRack

Sieć prywatna w OVH - vRack

Widok sieci prywatnych vRack

Sieć prywatna w OVH - vRack

Widok sieci w OpenStack Horizon

Sieć prywatna w OVH - vRack

➜  ~ neutron net-show Private-Net
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
+--------------------------+--------------------------------------+
| Field                    | Value                                |
+--------------------------+--------------------------------------+
| admin_state_up           | True                                 |
| availability_zone_hints  |                                      |
| availability_zones       | nova                                 |
| created_at               | 2018-02-13T10:44:43Z                 |
| description              |                                      |
| id                       | adc65d0c-abd3-47d9-a1a3-96ed4ea50485 |
| ipv4_address_scope       |                                      |
| ipv6_address_scope       |                                      |
| mtu                      | 9000                                 |
| name                     | Private-Net                          |
| project_id               | 84506b08626d4e03a581d170f3bc53d2     |
| provider:network_type    | vrack                                |
| provider:segmentation_id | 0                                    |
| qos_policy_id            |                                      |
| revision_number          | 4                                    |
| router:external          | False                                |
| shared                   | False                                |
| status                   | ACTIVE                               |
| subnets                  | b55fd630-79e4-4101-9d30-12ba693533ca |
| tags                     |                                      |
| tenant_id                | 84506b08626d4e03a581d170f3bc53d2     |
| updated_at               | 2018-02-13T10:44:49Z                 |
+--------------------------+--------------------------------------+

Sieć prywatna w OVH - vRack

➜  ~ neutron subnet-show b55fd630-79e4-4101-9d30-12ba693533ca
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
+-------------------+----------------------------------------------------+
| Field             | Value                                              |
+-------------------+----------------------------------------------------+
| allocation_pools  | {"start": "192.168.0.214", "end": "192.168.0.254"} |
| cidr              | 192.168.0.0/24                                     |
| created_at        | 2018-02-13T10:44:49Z                               |
| description       |                                                    |
| dns_nameservers   |                                                    |
| enable_dhcp       | True                                               |
| gateway_ip        |                                                    |
| host_routes       |                                                    |
| id                | b55fd630-79e4-4101-9d30-12ba693533ca               |
| ip_version        | 4                                                  |
| ipv6_address_mode |                                                    |
| ipv6_ra_mode      |                                                    |
| name              |                                                    |
| network_id        | adc65d0c-abd3-47d9-a1a3-96ed4ea50485               |
| project_id        | 84506b08626d4e03a581d170f3bc53d2                   |
| revision_number   | 2                                                  |
| service_types     |                                                    |
| subnetpool_id     |                                                    |
| tenant_id         | 84506b08626d4e03a581d170f3bc53d2                   |
| updated_at        | 2018-02-13T10:44:49Z                               |
+-------------------+----------------------------------------------------+

Sieć prywatna w OVH - vRack

Oto przykład, na którym jest widoczne, jak można uruchomić instancję z poziomu OpenStack API z dodatkowym interfejsem oraz jak podłączyć dodatkowy interfejs sieci prywatnej do działającej instancji.

nova list --fields name,status
nova list --fields name,networks

nova boot --flavor s1-4 --image "Ubuntu 16.04" --nic net-name=Ext-Net --nic net-name=Private-Net --key-name psuder_desktop testing
nova list --fields name,status
nova list --fields name,status
nova list --fields name,networks | grep 192.168.0.218
nova delete 735c849c-ad24-4093-8f33-5ce005c2470e

neutron net-list | grep Private-Net
nova interface-attach web-1 --net-id adc65d0c-abd3-47d9-a1a3-96ed4ea50485
ssh ubuntu@54.38.136.26
ip link
sudo dhclient ens6

nova list --fields name,networks | grep 192.168.0.218

Sieć prywatna w OVH - vRack

➜  ~ nova list --fields name,status,networks
+--------------------------------------+-------+--------+----------------------------------------------------------------------------+
| ID                                   | Name  | Status | Networks                                                                   |
+--------------------------------------+-------+--------+----------------------------------------------------------------------------+
| 9c1097ae-2e7e-4244-91b6-017ed75191b4 | db-1  | ACTIVE | Ext-Net=145.239.28.190, 2001:41d0:601:2000::245; Private-Net=192.168.0.224 |
| a8337ef7-693b-4f8f-a90c-b5d4ed087528 | web-1 | ACTIVE | Ext-Net=54.38.136.26, 2001:41d0:601:2000::26c; Private-Net=192.168.0.218   |
+--------------------------------------+-------+--------+----------------------------------------------------------------------------+

Widok listy instancji z dwoma sieciami

Sieć prywatna w OVH - vRack

ubuntu@web-1:~$ mtr -r -c 1 192.168.0.224
Start: Tue Feb 13 13:17:33 2018
HOST: web-1                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.0.224              0.0%     1    1.4   1.4   1.4   1.4   0.0

ubuntu@web-1:~$ mtr -r -c 1 145.239.28.190
Start: Tue Feb 13 13:17:52 2018
HOST: web-1                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 54.38.136.1                0.0%     1    0.2   0.2   0.2   0.2   0.0
  2.|-- 192.168.250.254            0.0%     1    0.1   0.1   0.1   0.1   0.0
  3.|-- 192.168.250.8              0.0%     1    0.3   0.3   0.3   0.3   0.0
  4.|-- ip-145-239-28.eu           0.0%     1    0.4   0.4   0.4   0.4   0.0

OpenStack

Automatyzacja

Publiczne API OpenStack
Narzędzia do automatyzacji: Ansible, Terraform, ...
Konteneryzacja aplikacji

Automatyzacja

Oto przykład, gdzie widać, jak z pomocą skryptu Ansible uruchamiane są dwie instancje i konfigurowane, tak aby można była na nich korzystać z mysqla i wordpressa.

ansible-playbook playbook-1.yml
nova list --fields name,status,networks
ssh ubuntu@54.37.130.17
sudo docker ps
mysql -u db_user -H 192.168.0.223 -p
show databases;
use db_wordpress;
show tables;

Automatyzacja

Widok instalacji Wordpressa

Automatyzacja

Widok Wordpressa

OpenStack

Przestrzeń dyskowa

Widok przestrzeni dyskowej

Przestrzeń dyskowa

Dodawanie nowego kontenera

Przestrzeń dyskowa

Instalowanie pluginu w Wordpress

Przestrzeń dyskowa

Konfigurowanie pluginu w Wordpress

Przestrzeń dyskowa

Dodawanie nowego użytkownika w projekcie OpenStack

Przestrzeń dyskowa

Pobranie konfiguracji dostępu do OpenStack API

Przestrzeń dyskowa

Pobranie konfiguracji dostępu do OpenStack API

Przestrzeń dyskowa

Konfiguracja pluginu w Wordpress

Przestrzeń dyskowa

OpenStack

Podsumowanie

OpenStack jest rozwiązaniem otwartym i tworzone jest przez community
OpenStacka można uruchamiać jako chmurę prywatną lub publiczną
Ze względu na powszechność OpenStacka, istnieje wiele narzędzi do automatyzacji

OpenStack

z punktu widzenia

dewelopera i operatora

O mnie

OpenStack

Moja historia

OpenStack - kiedyś

OpenStack - teraz

OpenStack

Historia

Fundacja

Technical Committee

Narzędzia i praca nad kodem

Lifecycle

Architektura

Instalacja

Wydarzenia i współpraca

Inne

OpenStack w OVH

Historia

Wdrożenie

Workflow pracy z kodem

Praca z upstreamem

Narzędzia

Usługa w OVH

OpenStack

Przykład użycia

Horizon

Horizon

Horizon

Horizon

Instancja

CLI API

Sieci w OVH OpenStack

Publiczna i prywatna vRack

Sieć publiczna w OVH

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

Sieć prywatna w OVH - vRack

OpenStack

Automatyzacja

Automatyzacja

Automatyzacja

Automatyzacja

Automatyzacja

OpenStack

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

Przestrzeń dyskowa

OpenStack

Podsumowanie

Podsumowanie

Pytania

Dziękuję