Własne Registry na klastrze kubernetesowym

A więc mamy klaster Kubernetesa i chcemy sobie na nim wdrożyć swoje własne Registry dockerowe.  W moim przypadku mam w klastrze 3 węzły z czego jeden główny, a wszystkie stoją na Ubuntu 16.04.4 LTS.

Abyśmy mogli w polu "image" ustawić nazwę FQDN naszej usługi Registry musimy zainstalować dnsmasq, które będzie korzystać z serwera DNS-owego Kubernetesa. Najpierw musimy sprawdzić jaki jest adres IP serwisu odwołującego się do serwera nazw domenowych Kubernetes (na jednym z węzłów zarządzających):

bkorpala@kubernetes-master1:~$ kubectl -n kube-system get services | grep kube-dns |  awk '{ print $3 }'
10.233.0.3

Następnie instalujemy na wszystkich węzłach usługę dnsmasq komendą "sudo apt install dnsmasq".

Kolejnym krokiem jest edycja pliku "/etc/dnsmasq.d/kube.conf" i wprowadzenie do niego poniższej zawartości (wraz z odpowiednim adresem IP usługi kube-dns):

server=/cluster.local/10.233.0.3

Teraz na wszystkich serwerach restartujemy sieć "sudo systemctl restart networking" oraz restartujemy dnsmasq poprzez "sudo systemctl restart dnsmasq".

Sprawdzamy czy np. adres "kube-dns.kube-system.svc.cluster.local" jest rozwiązywane na IP przy użyciu pinga. Musimy się także upewnić, że w "/etc/resolv.conf" zawsze na pierwszym miejscu będzie "nameserver 127.0.0.1" bo w przeciwnym wypadku nazwy mogą nie być rozwiązywane. Dobrze zrestartować serwer i sprawdzić co się pojawi w "/etc/resolv.conf". Dla pewności można też dodać wpis "nameserver 127.0.0.1" do "/etc/resolvconf/resolv.conf.d/head" i wykonać komendę "sudo resolvconf -u".

Następny punkt dotyczy wygenerowania ceryfikatu dla HTTPS w Registry:

bkorpala@MacBook-Pro-Bartlomiej:~|⇒  openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout registry.key -out registry.crt
Generating a 2048 bit RSA private key
........................+++
............................+++
writing new private key to '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) []:PL
State or Province Name (full name) []:Malopolskie
Locality Name (eg, city) []:Krakow
Organization Name (eg, company) []:Nazwa_firmy
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:kube-registry.registry.svc.cluster.local
Email Address []:adres_poczty

Tworzymy przestrzeń nazw komendą "kubectl create namespace registry".

Certyfikat i klucz prywatny będziemy trzymać w sekretach Kubernetesa, ale najpierw musimy je przekonwertować do Base64 jak np.:

bkorpala@kubernetes-master1:~$ cat registry.crt | base64 -w0
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR0RENDQXB3Q0NRQzlPSXoyN21EaDVEQU5CZ2txaGtpRzl3MEJBUXNGQURDQm16RUxNQWtHQTFVRUJoTUMKVUV3eEZEQVNCZ05WQkFnTUMwMWhiRzl3YjJ4emEybGxNUTh3RFFZRFZRUUhEQVpMY21GcmIzY3hFREFPQmdOVgpCQW9NQjAxcGNYVnBaRzh4TVRBdkJnTlZCQU1NS0d0MVltVXRjbVZuYVhOMGNua3VjbVZuYVhOMGNua3VjM1pqCkxtTnNkWE4wWlhJdWJHOWpZV3d4SURBZUJna3Foa2lHOXcwQkNRRVdFV2hsYkd4dlFHMXBjWFZwWkc4dVkyOXQKTUI0WERURTRNRGN3TWpFeU1ETXdOVm9YRFRFNU1EY3dNakV5TURNd05Wb3dnWnN4Q3pBSkJnTlZCQVlUQWxCTQpNUlF3RWdZRFZRUUlEQXROWVd4dmNHOXNjMnRwWlRFUE1BMEdBMVVFQnd3R1MzSmhhMjkzTVJBd0RnWURWUVFLCkRBZE5hWEYxYVdSdk1URXdMd1lEVlFRRERDaHJkV0psTFhKbFoybHpkSEo1TG5KbFoybHpkSEo1TG5OMll5NWoKYkhWemRHVnlMbXh2WTJGc01TQXdIZ1lKS29aSWh2Y05BUWtCRmhGb1pXeHNiMEJ0YVhGMWFXUnZMbU52YlRDQwpBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUs2RW1ZT2lKejZydmNPUjByV3RTVHkyClVhSTdPU2tPOU5kT1BIUUdQRjhsbjNpVUJ6MCtDeEJaRzEra2lxMmtSRVlJc1JDbkJ3RGMyNkdNYWowM0NicUcKbWlTOUpTSklHMCtBMEoxdWsrUDdqNnUzdURaMEhlRWdHeHpqK2ZmazNtUWpOcysrMms4TDVTRTFVM2lhRUhiRAphUVR4cVcyMFM5VXFXWjFxT21lZExaN0hhQ0VBa1BQU0xOeitwUnlIbElianVPM0lPam5Za1c1V2ZCRTBpU0ZTCnhxRFdpL2lYTGtHOFRwZDExYWZ0amFPRHJjRklISzF0NTJyV0w3cUtvOVFLdVpXSFM1RjNReFdYbHVKM09ndU0KSEVQZzVtaDk2MlRGeVVzN2gvOWVicXV0akxmMk9FY2Q1YlNUZXNqbk1sZWZNN2lrN2tUYXBwTC84TGVSNGo4QwpBd0VBQVRBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQWRtbkc5eTlSYXlFaFhqdEtYcjB5cW1TUitmTFFHMkZXCnB6TDRwTDJ1ZzNIQWVDS0Y0ZEgyak9qRUhVYjN6TU9sVW5zRGRvMDlOa1I2eGRrWXFXYXJWc3I4RGlHZ3h1LzcKb2YrZnIybUdYNFJtNmlqekgwcXRIMWlsdzA0OGwrNER2L1VVcjJwZWthTUMrMHhmU1U2c3B0NXNYWk1LS0JPRQpMUjFKbE1BeWI0OEd1Y2E0Tko2bUw4L2dxcVUvb25WQTVPbDBoOGtyZHNONzUrUStQTThibitTYVQ2bjdaTlVKCmZ6dllyTmU1Ynp2aXdyc0ZYcnBOR2VBWVpnV01BZS9CU1NReUpjZHpDSjg4YW8yazlocHNYbi9XUGtOcUVJUFAKOGZOMkZNbHlaTDFQMmFDQ2ZjSUREZGZGYzlWWW0vbGQ0REZlN2IyT1IvWVlpWUtiNXhsMmdnPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=

Gdy już mamy zakodowaną wartość to tworzymy pierwszą część manifestu:

apiVersion: v1
kind: Secret
metadata:
  name: registry-certs
type: Opaque
data:
  registry.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR0RENDQXB3Q0NRQzlPSXoyN21EaDVEQU5CZ2txaGtpRzl3MEJBUXNGQURDQm16RUxNQWtHQTFVRUJoTUMKVUV3eEZEQVNCZ05WQkFnTUMwMWhiRzl3YjJ4emEybGxNUTh3RFFZRFZRUUhEQVpMY21GcmIzY3hFREFPQmdOVgpCQW9NQjAxcGNYVnBaRzh4TVRBdkJnTlZCQU1NS0d0MVltVXRjbVZuYVhOMGNua3VjbVZuYVhOMGNua3VjM1pqCkxtTnNkWE4wWlhJdWJHOWpZV3d4SURBZUJna3Foa2lHOXcwQkNRRVdFV2hsYkd4dlFHMXBjWFZwWkc4dVkyOXQKTUI0WERURTRNRGN3TWpFeU1ETXdOVm9YRFRFNU1EY3dNakV5TURNd05Wb3dnWnN4Q3pBSkJnTlZCQVlUQWxCTQpNUlF3RWdZRFZRUUlEQXROWVd4dmNHOXNjMnRwWlRFUE1BMEdBMVVFQnd3R1MzSmhhMjkzTVJBd0RnWURWUVFLCkRBZE5hWEYxYVdSdk1URXdMd1lEVlFRRERDaHJkV0psTFhKbFoybHpkSEo1TG5KbFoybHpkSEo1TG5OMll5NWoKYkhWemRHVnlMbXh2WTJGc01TQXdIZ1lKS29aSWh2Y05BUWtCRmhGb1pXeHNiMEJ0YVhGMWFXUnZMbU52YlRDQwpBU0l3RFFZSktvWklodmNOQVFFQkJRQURnZ0VQQURDQ0FRb0NnZ0VCQUs2RW1ZT2lKejZydmNPUjByV3RTVHkyClVhSTdPU2tPOU5kT1BIUUdQRjhsbjNpVUJ6MCtDeEJaRzEra2lxMmtSRVlJc1JDbkJ3RGMyNkdNYWowM0NicUcKbWlTOUpTSklHMCtBMEoxdWsrUDdqNnUzdURaMEhlRWdHeHpqK2ZmazNtUWpOcysrMms4TDVTRTFVM2lhRUhiRAphUVR4cVcyMFM5VXFXWjFxT21lZExaN0hhQ0VBa1BQU0xOeitwUnlIbElianVPM0lPam5Za1c1V2ZCRTBpU0ZTCnhxRFdpL2lYTGtHOFRwZDExYWZ0amFPRHJjRklISzF0NTJyV0w3cUtvOVFLdVpXSFM1RjNReFdYbHVKM09ndU0KSEVQZzVtaDk2MlRGeVVzN2gvOWVicXV0akxmMk9FY2Q1YlNUZXNqbk1sZWZNN2lrN2tUYXBwTC84TGVSNGo4QwpBd0VBQVRBTkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQWRtbkc5eTlSYXlFaFhqdEtYcjB5cW1TUitmTFFHMkZXCnB6TDRwTDJ1ZzNIQWVDS0Y0ZEgyak9qRUhVYjN6TU9sVW5zRGRvMDlOa1I2eGRrWXFXYXJWc3I4RGlHZ3h1LzcKb2YrZnIybUdYNFJtNmlqekgwcXRIMWlsdzA0OGwrNER2L1VVcjJwZWthTUMrMHhmU1U2c3B0NXNYWk1LS0JPRQpMUjFKbE1BeWI0OEd1Y2E0Tko2bUw4L2dxcVUvb25WQTVPbDBoOGtyZHNONzUrUStQTThibitTYVQ2bjdaTlVKCmZ6dllyTmU1Ynp2aXdyc0ZYcnBOR2VBWVpnV01BZS9CU1NReUpjZHpDSjg4YW8yazlocHNYbi9XUGtOcUVJUFAKOGZOMkZNbHlaTDFQMmFDQ2ZjSUREZGZGYzlWWW0vbGQ0REZlN2IyT1IvWVlpWUtiNXhsMmdnPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
  registry.key: LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUV2UUlCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQktjd2dnU2pBZ0VBQW9JQkFRQ3VoSm1Eb2ljK3E3M0QKa2RLMXJVazh0bEdpT3prcER2VFhUangwQmp4ZkpaOTRsQWM5UGdzUVdSdGZwSXF0cEVSR0NMRVFwd2NBM051aApqR285TndtNmhwb2t2U1VpU0J0UGdOQ2RicFBqKzQrcnQ3ZzJkQjNoSUJzYzQvbjM1TjVrSXpiUHZ0cFBDK1VoCk5WTjRtaEIydzJrRThhbHR0RXZWS2xtZGFqcG5uUzJleDJnaEFKRHowaXpjL3FVY2g1U0c0N2p0eURvNTJKRnUKVm53Uk5Ja2hVc2FnMW92NGx5NUJ2RTZYZGRXbjdZMmpnNjNCU0J5dGJlZHExaSs2aXFQVUNybVZoMHVSZDBNVgpsNWJpZHpvTGpCeEQ0T1pvZmV0a3hjbExPNGYvWG02cnJZeTM5amhISGVXMGszckk1ekpYbnpPNHBPNUUycWFTCi8vQzNrZUkvQWdNQkFBRUNnZ0VBSENPSE9TRkJJS3JDV3pFOC8wd2tmZVNMdnhPN2dMSkhxaHVVUmNUbm9SUEkKNWNGQWRaQjJhamxqMzRVQlUwUWtPZ0tXd2krY1FuaFo5VzlWaGU5RTQwMW10enZFTEFYaVdXeFV0cjJvbk43bgo2SEVrQTZ1dlVhaENsdUx2WUJnSC82OXAzQTlTMWVIK0hOK2pTTlBXaWIreVJEak83OEJkWmM2QlNvOWhRV2xqClVweHV2MXB1ZUZIK2trckljazh3aEhJQ2pnQWlwNTl4MWRUbmRNVWI5M0N3UkxZaW1HUG1yTE9ydTU1K0tEUEoKbkVLT0FPT0JQMXE1RTFaN25sZ3RQUEVDZHhxWnVMc2NaT24xVXBFR05WN2o0YkJYeUI3VTV1KzhVcWUwWUhvcwowdmdTa2hEbHBGZkx5M0xoVTBVelBCcFBlbXYrR2pZUDRiUGhDZll6b1FLQmdRRFZMR0duazNOeDI3MTZNR2krCngwTmtCaVJtVjVrWEJROVhpWjgySlNPTVF2ZmJ0d3ArU1o3MS9adm9yNmY2Tnhac1BIL2RTaE4wd2dnaG9OcHoKYkhYK09IQjRmZWxMc1NJeDhqQUNkdERnd1BkTCtPRStPdUNtT01KNWE4OE4yRmRHQXAyME0yRzBDK2oxOXE1Rwo5c2RDVnRUbkVJVm5nOHJkWit6NFFRUVcwUUtCZ1FEUmxDYVYyTmVybHJtY0EveFZ5OXo5UmVPRVRJVHVjbkNTCkhvQ0o3dlczRzRqNm9HR2swYXlJK1VodkNDUVBYWUpSaWY1bnpBaTY4TXo5b1JtVllKNW9lMW5zWk9YUGlXTlAKRzlaaXE4cjExU0VtbnlmV1MwQ20rcmlYYzhMWDUzSFIrWmZFVDB1SGtaWmZJUERKd1E2QnF6dlZsek9sVXFoNwpldUd0R1ViTUR3S0JnRUU3dHBxSVJjQ201TUc2aEtNMDZRdDMwYlc3d3E1SHJ4MHprUlFKbzJvdHFCbUZWdUcwCmQ3K0JIeS9DYVIzcHM2UGxrNTlOSnMwSS8ySUREalphRDNWL0lmUE5YQkg4bjZFM0lyZnVVaGNsRmNnYTNocWoKKzlFQjk0a2VrNXNDQkJyNWUvY0Q3amNobWVXQzJtdis0cFVMYTFWV09leW1hUEw5OVljMnBpQ3hBb0dBU3dxTApEbGlJVUs0MVk0R2gxbTZhZ0MySUc1VHlmQmFKN0NmenltKy9sNExLZDBMNTgzUUlIVHQxRGh5U0hOWlVsVEdkCjREaVVYNnRkR3V1V0o0Qmk5L0pDN252cU5YZHlFWjljRWhTRkphVGNxK0dNK0JRVjREUWg2RWpRMlZITDFXMVQKUkQxSVJCQ0RFU2pRVHMxTGptNXJqRDBKaHdhandTTHNyM2cvZTAwQ2dZRUFsZjkrU1NManVxU0JCbmFDY0NLbApTbW5rM2RJMmxYOG5kY0RiUTVyOXhWTHJXcXBIK1BwSkIrUk45VWpVTWlrdFZrYmYrbjNwOVp5T2NxeG9YVk9wClRYMXY0Y0NjbDR5cC9xOXhtOU5FNGhRSkVsRm10YTlwMVJ3a2JmeWpqTnVVOUlMZjljM21MMlN0STFTV3gyUjAKWmlpT3hvUXdUSlFvK2phdlR4dUJHeFU9Ci0tLS0tRU5EIFBSSVZBVEUgS0VZLS0tLS0K

Wgrywamy za pomocą komendy "kubectl apply -n registry -f registry_deployment.yml" i sprawdzamy jak nam poszło:

bkorpala@kubernetes-master1:~$ kubectl -n registry get secrets
NAME                  TYPE                                  DATA      AGE
default-token-k8x4m   kubernetes.io/service-account-token   3         51m
registry-certs        Opaque

Dalej musimy stworzyć usługę, która umożliwi nam komunikację z naszym kontenerem Registry (dodajemy do naszego manifestu oddzielając "---"):

apiVersion: v1
kind: Service
metadata:
  name: kube-registry
  labels:
    k8s-app: kube-registry-upstream
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "KubeRegistry"
spec:
  selector:
    k8s-app: kube-registry-upstream
  ports:
  - name: registry
    port: 443
    protocol: TCP

Standardowo sprawdźmy co zrobiliśmy:

bkorpala@kubernetes-master1:~$ kubectl -n registry get services
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
glusterfs-cluster   ClusterIP   10.233.28.208   <none>        1/TCP     18h
kube-registry       ClusterIP   10.233.29.16    <none>        443/TCP   10m

Teraz musimy zadeklarować obiekty PersistentVolume i PersistentVolumeClaim określające ilość miejsca, które możemy wykorzystać (dla mojego przykładu do przechowywania danych użyłem GlusterFS, na temat którego możecie przeczytać tutaj):

kind: PersistentVolume
apiVersion: v1
metadata:
  name: kube-registry-pv
  labels:
    kubernetes.io/cluster-service: "true"
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  glusterfs:
    endpoints: glusterfs-cluster
    path: registry
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: kube-registry-pvc
  labels:
    kubernetes.io/cluster-service: "true"
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1500M

Wynik powinien być zbliżony do tego:

bkorpala@kubernetes-master1:~$ kubectl -n registry get pv
NAME               CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                        STORAGECLASS   REASON    AGE
kube-registry-pv   2Gi        RWO            Retain           Bound     registry/kube-registry-pvc                            9s
bkorpala@kubernetes-master1:~$ kubectl -n registry get pvc
NAME                STATUS    VOLUME             CAPACITY   ACCESS MODES   STORAGECLASS   AGE
kube-registry-pvc   Bound     kube-registry-pv   2Gi        RWO                           11s

Teraz najważniejsza rzecz czyli wdrożenie naszego strąka z Docker Registry:

apiVersion: v1
kind: ReplicationController
metadata:
  name: kube-registry-v0
  labels:
    k8s-app: kube-registry-upstream
    version: v0
    kubernetes.io/cluster-service: "true"
spec:
  replicas: 1
  selector:
    k8s-app: kube-registry-upstream
    version: v0
  template:
    metadata:
      labels:
        k8s-app: kube-registry-upstream
        version: v0
        kubernetes.io/cluster-service: "true"
    spec:
      containers:
      - name: registry
        image: registry:2
        resources:
          limits:
            cpu: 100m
            memory: 100Mi
        env:
        - name: REGISTRY_HTTP_ADDR
          value: :443
        - name: REGISTRY_HTTP_TLS_CERTIFICATE
          value: /certs/registry.crt
        - name: REGISTRY_HTTP_TLS_KEY
          value: /certs/registry.key
        - name: REGISTRY_STORAGE_FILESYSTEM_ROOTDIRECTORY
          value: /var/lib/registry
        volumeMounts:
        - name: registry-vol
          mountPath: /var/lib/registry
          subPath: registry
        - name: registry-certs-vol
          mountPath: /certs
        ports:
        - containerPort: 443
          name: registry
          protocol: TCP
      volumes:
      - name: registry-vol
        persistentVolumeClaim:
          claimName: kube-registry-pvc
      - name: registry-certs-vol
        secret:
          secretName: registry-certs

Pobierzmy rezultat:

bkorpala@kubernetes-master1:~$ kubectl -n registry get rc
NAME               DESIRED   CURRENT   READY     AGE
kube-registry-v0   1         1         1         26s
bkorpala@kubernetes-master1:~$ kubectl -n registry get pods
NAME                     READY     STATUS    RESTARTS   AGE
kube-registry-v0-xshs8   1/1       Running   0          35s

Teraz z dowolnego węzła Kubernetes możemy pingować nasz strąk i nazwa domeny powinna zostać rozwiązana na adres IP:

bkorpala@kubernetes-master1:~$ ping kube-registry.registry.svc.cluster.local
PING kube-registry.registry.svc.cluster.local (10.233.29.16) 56(84) bytes of data.

Sprawdźmy zatem czy Registry działa:

bkorpala@kubernetes-master1:~$ curl -k https://kube-registry.registry.svc.cluster.local/v2/_catalog
{"repositories":[]}

Pasuje coś wrzucić do naszego rejestru. Niechaj to będzie Nginx. Za pomocą komendy "docker pull nginx" pobieramy ostatnią wersję obrazu. Teraz pobieramy identyfikator obrazu:

bkorpala@kubernetes-master1:~$ sudo docker images | grep latest | grep nginx
nginx                                                 latest              5699ececb21c        6 days ago          109 MB

Komendą "docker tag 5699ececb21c kube-registry.registry.svc.cluster.local/nginx" oznaczamy nasz obraz celem wypchnięcia go na prywatne Registry: "docker push kube-registry.registry.svc.cluster.local/nginx". Standardowo weryfikujemy:

bkorpala@kubernetes-master1:~$ curl -k https://kube-registry.registry.svc.cluster.local/v2/_catalog
{"repositories":["nginx"]}
bkorpala@kubernetes-master1:~$ curl -k https://kube-registry.registry.svc.cluster.local/v2/nginx/tags/list
{"name":"nginx","tags":["latest"]}

Teraz definiując manifest w polu "image" dla konkretnego kontenera możemy użyć wyżej wymienionego adresu.

Jeżeli krok z dnsmasq pominęliśmy lub zwyczajnie nie chcemy w ten sposób rozwiązywać nazw to możemy stworzyć usługę, która na każdym z węzłów wystawi nam Registry na konkretnym porcie:

apiVersion: v1
kind: Service
metadata:
  name: kube-registry-every-node
  labels:
    k8s-app: kube-registry-upstream
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: "KubeRegistry"
spec:
  selector:
    k8s-app: kube-registry-upstream
  type: NodePort
  ports:
  - name: registry-every-node
    nodePort: 31337
    port: 443
    protocol: TCP

Sprawdźmy jak poszło:

bkorpala@kubernetes-master1:~$ sudo kubectl -n registry get services
NAME                       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)         AGE
glusterfs-cluster          ClusterIP   10.233.28.208   <none>        1/TCP           21h
kube-registry              ClusterIP   10.233.29.16    <none>        443/TCP         3h
kube-registry-every-node   NodePort    10.233.8.16     <none>        443:31337/TCP   30s
bkorpala@kubernetes-master1:~$ curl -k https://localhost:31337/v2/_catalog
{"repositories":["nginx"]}

Jeżeli chcemy tylko tymczasowo sprawdzić poprawność działania to możemy zwyczajnie przekazać konkretny port do naszej stacji roboczej:

bkorpala@kubernetes-master1:~$ sudo kubectl port-forward --namespace registry kube-registry-v0-xshs8 31337:443 &
[1] 20103
bkorpala@kubernetes-master1:~$ Forwarding from 127.0.0.1:31337 -> 443
bkorpala@kubernetes-master1:~$ curl -k https://localhost:31337/v2/_catalog
Handling connection for 31337
{"repositories":["nginx"]}
E0703 12:01:31.963822   20104 portforward.go:316] error copying from local connection to remote stream: read tcp4 127.0.0.1:31337->127.0.0.1:46754: read: connection reset by peer 

Kubernetes z GlusterFS jako miejsce składowania danych

Gdy już mamy GlusterFS (jako przewodnik możesz wykorzystać ten link) to musimy usunąć restrykcję mówiącą, że masz wolumen może być montowany tylko z localhost:

root@kubernetes-master1:~# gluster volume reset gvol0 auth.allow
volume reset: success: reset volume successful

Stworzyliśmy również klaster Kubernetes (np. dzięki temu). Najpierw tworzymy punkt końcowy dla usługi aby określić szczegóły dostępu do GlusterFS. Tworzymy plik "glusterfs-endpoints.yml" o poniższej zawartości:

apiVersion: v1
kind: Endpoints
metadata:
  name: glusterfs-cluster
subsets:
  - addresses:
      - ip: 192.168.33.30
    ports:
      - port: 1
  - addresses:
      - ip: 192.168.33.31
    ports:
      - port: 1
  - addresses:
      - ip: 192.168.33.32
    ports:
      - port: 1
  - addresses:
      - ip: 192.168.33.33
    ports:
      - port: 1

Podajemy adresy naszych węzłów w GlusterFS (numer portu jest pomijany) i wdrażamy:

root@kubernetes-master1:~# kubectl create -f glusterfs-endpoints.yml
endpoints "glusterfs-cluster" created

Warto sprawdzić czy nam się udało:

root@kubernetes-master1:~# kubectl get endpoints
NAME                ENDPOINTS                                                     AGE
glusterfs-cluster   192.168.33.30:1,192.168.33.31:1,192.168.33.32:1 + 1 more...   11s
kubernetes          192.168.33.30:6443                                            6d 

Kolejnym krokiem jest definicja usługi:

apiVersion: v1
kind: Service
metadata:
  name: glusterfs-cluster
spec:
  ports:
  - port: 1

Pole "name" musi odpowiadać nazwie w definicji punktów końcowych. Wdrażamy i sprawdzamy jak nam poszło:

root@kubernetes-master1:~# kubectl create -f glusterfs-service.yml
service "glusterfs-cluster" created
root@kubernetes-master1:~# kubectl get services
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
glusterfs-cluster   ClusterIP   10.109.25.207   <none>        1/TCP     4s
kubernetes          ClusterIP   10.96.0.1       <none>        443/TCP   6d

Przechodzimy do definicji obiektu PersistentVolume czyli niskopoziomowej reprezentacji wolumenu przechowywania danych. Odwołujemy się do punktu końcowego aby poinformować Kubernetes gdzie klaster GlusterFS jest dosępny oraz jaka jest nazwa wolumenu, który utworzono. Tworzymy plik "glusterfs-persistent-volume.yml":

apiVersion: v1
kind: PersistentVolume
metadata:
  name: fileupload-vol
  labels:
    dev: dev
spec:
  accessModes:
  - ReadWriteMany
  capacity:
    storage: 500M
  glusterfs:
    endpoints: glusterfs-cluster
    path: gvol0
  persistentVolumeReclaimPolicy: Recycle

W polu "path" podajemy nazwę naszego wolumenu i uruchamiamy:

root@kubernetes-master1:~# kubectl create -f glusterfs-persistent-volume.yml
persistentvolume "fileupload-vol" created
root@kubernetes-master1:~# kubectl get pv
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
fileupload-vol   500M       RWX            Recycle          Available                                      6s 

Kolejno musimy utworzyć obiekt PersistentVolumeClaim, który wiąże "strąk" ("pod") z obiektem PersistentVolume. Definicja w pliku "glusterfs-persistent-volume-claim.yml":

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: file-upload-claim
spec:
  accessModes:
  - ReadWriteMany
  resources:
     requests:
       storage: 100M

Sprawdźmy jak nam poszło:

root@kubernetes-master1:~# kubectl create -f glusterfs-persistent-volume-claim.yml
persistentvolumeclaim "file-upload-claim" created
root@kubernetes-master1:~# kubectl get pvc
NAME                STATUS    VOLUME           CAPACITY   ACCESS MODES   STORAGECLASS   AGE
file-upload-claim   Bound     fileupload-vol   500M       RWX                           4s

Ostatecznie w pliku "nginx.yml" piszemy definicję usługi. W naszym przypadku będzie to serwer Nginx:

apiVersion: v1
kind: List
items:
- apiVersion: extensions/v1beta1
  kind: Deployment
  metadata:
    name: nginx
  spec:
    replicas: 1
    template:
      metadata:
        labels:
          app: nginx
      spec:
        containers:
        - name: nginx
          image: nginx
          volumeMounts:
          - mountPath: /usr/share/nginx/html/
            name: dir-1
        volumes:
          - name: dir-1
            persistentVolumeClaim:
              claimName: file-upload-claim 

Pole "claimName" musi odpowiadać definicji obiektu PersistentVolumeClaim zaś w polu "mountPath" określamy jaki katalog w kontenerach chcemy współdzielić. Wdrażamy, sprawdzamy jakie mamy usługi, "strąki" oraz wchodzimy do kontenera z Nginksem:

root@kubernetes-master1:~# kubectl create -f nginx.yml
deployment.extensions "nginx" created
root@kubernetes-master1:~# kubectl get services
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
glusterfs-cluster   ClusterIP   10.109.25.207   <none>        1/TCP     22m
kubernetes          ClusterIP   10.96.0.1       <none>        443/TCP   6d
root@kubernetes-master1:~# kubectl get pods
NAME                    READY     STATUS    RESTARTS   AGE
nginx-944f45fb8-ztv92   1/1       Running   0          59s
root@kubernetes-master1:~# kubectl exec -it nginx-944f45fb8-ztv92 -- /bin/bash
root@nginx-944f45fb8-ztv92:/#

Tak przygotowane rozwiązanie pozwala nam na współdzielenie plików w kontenerach Nginx (katalog "/usr/share/nginx/html") i na komputerach gdzie jest GlusterFS.

TeamCity - migracja do kontenera dockerowego

Niniejsza pozycja omawia przejście z serwera CI CD TeamCity w wersji 9.1.7 do TeamCity w wersji 2017.2.3 umieszczonego w kontenerze dockerowym pod kontrolą Docker Swarm. Bazą danych, którą wykorzystano w przykładzie jest MySQL.

Pierwszym krokiem, który musimy jest wykonanie kopii zapasowej TeamCity:

• prawy górny róg i "Administration",
• belka po lewej i "Backup",
• z listy rozwijanej "Backup scope" określamy co ma zawierać kopia, a wybranie opcji "Custom" pozwala nam na indywidualne określenie zakresu,
• możemy określić nazwę pliku w sekcji "Backup file"
• pole "add timestamp suffix" doda nam w nazwie pliku kopii zapasowej wzorzec daty i czasu,
• naciskamy "Start Backup".

Kopię można również wykonać za pomocą dedykowanego narzędzia znajdującego się w katalogu z instalacją TC. Dla przykładu w moim wypadku będzie to wywołanie "/home/teamcity/teamcity/bin/maintainDB.sh -C -D -L -P".

Oczekujemy na zakończenie wykonywania się kopii zapasowej (będzie miała rozszerzenie "zip"). W podsumowaniu znajduje się ścieżka do pliku.

W związku z tym, że kopia nie obejmuje artefaktów to musimy je skopiować sami jeżeli chcemy je również mieć w nowej instancji TC.

Udajemy się do katalogu z artefaktami, który jest zależy od tego gdzie jest zainstalowane TC. W moim przypadku jest to "/home/teamcity/.BuildServer/system/artifacts" i wydajemy tam komendę

tar -czvf artifacts.tar.gz .

Przenosimy archiwa z kopią zapasową i artefaktami na serwer docelowy gdzie będzie stało nasze TeamCity w kontenerze.

Teraz przyszła pora na wdrożenie naszego nowego TC na docelowej maszynie. Ja zrobię to przy pomocy Ansible'a uruchamiają plik Docker Compose'a stworzony z szablonu Ansible, który ma następującą postać:

version: '3.5' 

services:
  mysql:
    image: mysql:5.7
    ports:
      - 3306:3306
    networks:
      - teamcity
    environment:
      MYSQL_ROOT_PASSWORD: {{ vault_mysql_root_password }}
      MYSQL_DATABASE: "{{ mysql_teamcity_database }}"
      MYSQL_USER: "{{ mysql_teamcity_user }}"
      MYSQL_PASSWORD: "{{ vault_mysql_teamcity_user_password }}"
    volumes:
      - mysql_data_directory:/var/lib/mysql
    deploy:
      replicas: 1
      placement:
        constraints: [node.role == manager]
      restart_policy:
        condition: on-failure 

  teamcity:
    image: jetbrains/teamcity-server:2017.2.3
    ports:
      - 8111:8111
    networks:
      - teamcity
      - traefik
    volumes:
      - teamcity_data_directory:/data/teamcity_server/datadir
      - teamcity_logs_directory:/opt/teamcity/logs
    deploy:
      replicas: 1
      placement:
        constraints: [node.role == manager]
      restart_policy:
        condition: on-failure
      labels:
        traefik.frontend.entryPoints: "http,https"
        traefik.frontend.rule: "Host:${HOST}"
        traefik.http.port: 8111
        traefik.backend: 

volumes:
  mysql_data_directory:
  teamcity_data_directory:
  teamcity_logs_directory: 

networks:
  teamcity:
    driver: overlay
    attachable: true
  traefik:
    external:
      name: traefik

A więc na docelowym serwerze mamy świeże i niezainicjalizowane TC w kontenerze dockerowym w Swarmie. Kolejnym krokiem jest uruchomienie dodatkowego kontenera z TeamCity współdzielącego wolumen, w którym dokonamy przywrócenia danych:

bkorpala@hercules:~$ sudo docker run -it --name restore-tc --rm --network=teamcity_teamcity --volumes-from=teamcity_teamcity.1.41rl6y4npfcb7pj7odvs4pfvo jetbrains/teamcity-server /bin/bash
   Welcome to TeamCity Server Docker container
 * Installation directory: /opt/teamcity
 * Logs directory:         /opt/teamcity/logs
 * Data directory:         /data/teamcity_server/datadir
root@73b7919e46dc:/#

Jako argument opcji "--network" podajemy sieć która została utworzona dla TC przez Swarma ("sudo docker network ls"), a dla opcji "--volumes-from" podajemy nazwę kontenera TC ("sudo docker ps").

Jeżeli chcemy wyjść z kontenera bez zabicia go to wciskamy najpierw klawisz Ctrl + P, a potem Ctrl + Q. Aby wejść znów do kontenera wpisujemy "sudo docker exec -it restore-tc /bin/bash".

Z pierwotnej instancji TC na serwer docelowy kopiujemy informację na temat połączenia z bazą danych. W moim przypadku jest to "/home/teamcity/.BuildServer/config/database.properties".

Otwieramy plik i modyfikujemy go wpisując użytkownika, hasło oraz nazwę bazy, które użyjemy w nowej instancji. Mój plik np. wygląda następująco:

# Database: HSQLDB (HyperSonic) version 2.x
connectionUrl=jdbc:mysql://mysql:3306/teamcity?useUnicode=yes&characterEncoding=UTF-8
connectionProperties.user=teamcity
connectionProperties.password=MGjHHVgm7ABSvnbP

Dzięki temu, że jesteśmy w zadeklarowanej przez nas sieci dockerowej to dla serwera MySQL możemy użyć nazwy domenowej, która odpowiada nazwie usługi w Docker Compose.

Do kontenera z dodatkowym TC kopiujemy plik z informacją na temat połączenia z bazą danych:

sudo docker cp database.properties restore-tc:/restore-database.properties

Kopiujemy tam również kopię bazy danych:

sudo docker cp TeamCity_Backup_Before_Update_20180601_200257.zip restore-tc:/backup.zip

 Następnie musimy pobrać sterownik dla połączeń z bazą danych MySQL ("https://dev.mysql.com/get/Downloads/Connector-J/mysql-connector-java-8.0.11.tar.gz") na serwer docelowy i go rozpakować. W kontenerze z dodatkowym TC tworzymy strukturę katalogów "/data/teamcity_server/datadir/lib/jdbc" i kopiujemy do niego nasz sterownik:

sudo docker cp mysql-connector-java-8.0.11/mysql-connector-java-8.0.11.jar restore-tc:/data/teamcity_server/datadir/lib/jdbc/

W kontenerze z dodatkowym TC wydajemy komendę, która zacznie proces odzyskiwania:

/opt/teamcity/bin/maintainDB.sh restore -A /data/teamcity_server/datadir/ -F /backup.zip -T /restore-database.properties

Po wgraniu kopii musimy jeszcze wgrać artefakty. Dla przykładu w moim wypadku (artefakty są umieszczone w folderach odpowiadających nazwom projektów) znajdują się one w katalogu "artifacts" po wypakowaniu archiwum, które wcześniej utworzyliśmy:

 sudo docker cp artifacts/. restore-tc:/data/teamcity_server/datadir/system/artifacts/

Uruchamiamy ponownie kontener z naszym nowym TC. W moim przypadku będzie to restart usługi Docker Swarma:

bkorpala@hercules:~$ sudo docker service scale teamcity_teamcity=0
teamcity_teamcity scaled to 0
overall progress: 0 out of 0 tasks
verify: Service converged
bkorpala@hercules:~$ sudo docker service scale teamcity_teamcity=1
teamcity_teamcity scaled to 1
overall progress: 1 out of 1 tasks
1/1: running   [==================================================>]
verify: Service converged

Wchodzimy na stronę z nowym TC i widzimy informację "TeamCity server requires technical maintenance. Please let the server administrator know this." i wtedy klikamy na "I'm a server administrator, show me the details". Musimy podać kod autoryzacyjny, który uzyskamy wchodząc do kontenera i odczytując logi jak np.:

bkorpala@hercules:~$ sudo docker exec -it teamcity_teamcity.1.foie75s0t5bk8grqz6jqm5xjw tail /opt/teamcity/logs/teamcity-server.log
[2018-06-03 04:04:46,377]   INFO -  jetbrains.buildServer.STARTUP - The database properties file "/data/teamcity_server/datadir/config/database.properties" doesn't exist
[2018-06-03 04:04:46,377]   INFO -  jetbrains.buildServer.STARTUP - The internal database data file "/data/teamcity_server/datadir/system/buildserver.data" doesn't exist
[2018-06-03 04:04:46,393]   INFO -  jetbrains.buildServer.STARTUP - Data Directory version: 727
[2018-06-03 04:04:46,393]   INFO -  jetbrains.buildServer.STARTUP - Current stage: Looking for the database configuration
[2018-06-03 04:04:46,393]   INFO -  jetbrains.buildServer.STARTUP - Database properties file "/data/teamcity_server/datadir/config/database.properties" doesn't exist
[2018-06-03 04:04:46,393]   INFO -  jetbrains.buildServer.STARTUP - Internal HSQL database file (/data/teamcity_server/datadir/system/buildserver.data) doesn't exist
[2018-06-03 04:04:46,393]   INFO -  jetbrains.buildServer.STARTUP - Neither database properties file nor internal database found.
[2018-06-03 04:04:46,393]  ERROR -  jetbrains.buildServer.STARTUP - Data parts are inconsistent: the Data Directory exists (from another version of TeamCity) but the database does not.
[2018-06-03 04:04:46,394]   INFO -  jetbrains.buildServer.STARTUP - Current stage: TeamCity server startup error
[2018-06-03 04:04:46,394]   INFO -  jetbrains.buildServer.STARTUP - Administrator can login from web UI using authentication token: 8288277720538082065

Widzimy, że brakuje nam plik z informacją na temat połączenia do bazy "/data/teamcity_server/datadir/config/database.properties" więc musimy go skopiować do kontenera i jeszcze raz zrestartować usługę w Docker Swarmie.

Kolejnym krokiem jest kliknięcie na "Confirm", a następnie "Upgrade". Teraz oczekujemy aż aktualizacja się zakończy.

Instalacja i konfiguracja GlusterFS

Dane wejściowe:

• 4 serwery Ubuntu 16.04.4 LTS,
• 2048 GB RAM-u każdy z serwerów.

Zaczynamy od wpisania do "/etc/hosts" każdego z serwerów informacji o nazwach i adresach IP wszystkich maszyn z naszej sieci GlusterFS. Dla przykładu:

192.168.33.30   kubernetes-master1192.168.33.31   kubernetes-worker1192.168.33.32   kubernetes-worker2192.168.33.33   kubernetes-worker3

Dodajemy wszędzie informację o repozytorium:

sudo add-apt-repository ppa:gluster/glusterfs-3.11

Aktualizujemy bazę:

sudo apt-get update

Instalujemy oprogramowanie:

sudo apt-get install glusterfs-server

Ze względów bezpieczeństwa wyłączamy aktualizację pakietów GlusterFS:

sudo apt-mark hold glusterfs*

Startujemy oprogramowanie i dodajemy konfigurację, która uruchamia usługę podczas startu systemu:

sudo systemctl start glusterd
sudo systemctl enable glusterd

Na pierwszy z serwerów sprawdzamy po kolei czy w sieci są dostępne wszystkie węzły:

vagrant@kubernetes-master1:~$ sudo gluster peer probe kubernetes-worker1
peer probe: success.
vagrant@kubernetes-master1:~$ sudo gluster peer probe kubernetes-worker2
peer probe: success.
vagrant@kubernetes-master1:~$ sudo gluster peer probe kubernetes-worker3
peer probe: success.

Tworzymy wolumen:

vagrant@kubernetes-master1:~$ sudo gluster volume create gvol0 replica 4 kubernetes-master1:/data kubernetes-worker1:/data kubernetes-worker2:/data kubernetes-worker3:/data force
volume create: gvol0: success: please start the volume to access data

Opcja "force" utworzy nam katalog na serwerach jeżeli takowy nie istnieje.

Aktualnie każdy komputer ma dostęp bez żadnych restrykcji do naszego wolumenu z danymi więc dopuszczamy połączenie montujące tylko z:

vagrant@kubernetes-master1:~$ sudo gluster volume set gvol0 auth.allow 127.0.0.1
volume set: success

Startujemy wolumen i wyświetlamy informacje na jego temat:

vagrant@kubernetes-master1:~$ sudo gluster volume start gvol0
volume start: gvol0: success
vagrant@kubernetes-master1:~$ sudo gluster volume status
Status of volume: gvol0
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick kubernetes-master1:/data              49152     0          Y       17935
Brick kubernetes-worker1:/data              49152     0          Y       8542
Brick kubernetes-worker2:/data              49152     0          Y       8411
Brick kubernetes-worker3:/data              49152     0          Y       8472
Self-heal Daemon on localhost               N/A       N/A        Y       17955
Self-heal Daemon on kubernetes-worker3      N/A       N/A        Y       8492
Self-heal Daemon on kubernetes-worker2      N/A       N/A        Y       8431
Self-heal Daemon on kubernetes-worker1      N/A       N/A        Y       8562
Task Status of Volume gvol0
------------------------------------------------------------------------------
There are no active volume tasks
vagrant@kubernetes-master1:~$ sudo gluster volume info
Volume Name: gvol0
Type: Replicate
Volume ID: ab3ed814-191e-4288-ae1e-341f9a1bca40
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 4 = 4
Transport-type: tcp
Bricks:
Brick1: kubernetes-master1:/data
Brick2: kubernetes-worker1:/data
Brick3: kubernetes-worker2:/data
Brick4: kubernetes-worker3:/data
Options Reconfigured:
auth.allow: 127.0.0.1
transport.address-family: inet
nfs.disable: on

Na każdym serwerze tworzymy katalog "/mnt/gluster".

Na każdej z maszyn montujemy wolumen (w zależności od tego na której jesteś to zmień nazwę) np.:

sudo mount -t glusterfs kubernetes-master1:/gvol0 /mnt/gluster

Teraz możemy manipulować zawartością tylko w "/mnt/gluster", ale pojawi sie ona również w katalogu "/data".

Każdej maszynie dodajemy wpis w "/etc/fstab" (w zależności od tego na której jesteś to zmień nazwę) np.:

kubernetes-master1:/gvol0 /mnt/gluster glusterfs defaults,_netdev 0 0

OpenShift i prywatne Docker Registry

Czasami zdarza się, że nasze obrazy kontenerów dockerowych przetrzymujemy w prywatnym rejestrze. Wymaga to wykonania przez nas dodatkowych operacji, które umożliwią nam pobranie danego obrazu.

Na początek logujemy się do OpenShifta tokenem

oc login https://127.0.0.1:8443 --token=viNUjgpTzIReqx-FHRU-c3XEEFojhio4tEQeJ5_3TgE

lub przez login i hasło

oc login -u admin -p admin

Kolejnym krokiem jest zalogowanie się do naszego Registry aby wygenerować plik z danymi uwierzytelniającymi:

docker login adres_serwera

Plik znajduje się pod adresem "/home/katalog_domowy/.docker/config.json". Teraz musimy wygenerować zasób przechowujący dane uwierzytelniające:

oc create secret generic mojeregistry --from-file=.dockerconfigjson=/katalog_domowy/.docker/config.json --type=kubernetes.io/dockerconfigjson

Dalej:

oc secrets link default mojeregistry --for=pull
oc secrets link builder mojeregistry --for=pull
oc secrets link deployer mojeregistry --for=pull

W tym miejscu mała dygresja, a mianowicie OpenShift domyślnie odpala aplikację w kontenerze jako użytkownik o losowym identyfikatorze celem bezpieczeństwa. Prawa są ograniczone i może się tak zdarzyć, że program nie będzie mógł się odpalić. Jeżeli nie można zmienić tego w OpenShifcie to konieczna jest modyfikacja Dockerfile'a. Aby dokonać zmiany w OpenShifcie najpierw wprowadzić

oc edit scc restricted

która otworzy nam plik jednego z Security Context Constraints.

Odnajdujemy linie

runAsUser:
   type: MustRunAsRange

i zamieniamy na

runAsUser:
   type: RunAsAny

Powyższe operacje umożliwią nam pobranie obrazu z prywatnego Registry.

Klaster Kubernetes

Dane wejściowe:

• 3 serwery wirtualne z Ubuntu 16.04 LTS,
• 2048 MB RAM-u,
• 2 procesory,
• wszystkie komendy uruchamiane jako root.

Na początek na każdym z serwerów wyłączamy partycję wymiany aby kubelet (agent uruchomiony na każdym węźle) działał poprawnie

1. wydajemy komendę "free -h" i sprawdzamy czy w linijce oznaczonej jako "Swap:" i kolumnie "total" mamy wartość różną od zera,
2. edytujemy plik "/etc/fstab" i komentujemy linijkę odpowiadającą za montowanie partycji wymiany,
3. restartujemy serwer. 

Kolejnym punktem jest instalacja Dockera na każdym z węzłów. Na początek aktualizujemy dane o pakietach:

apt-get update

Instalujemy potrzebne oprogramowanie:

apt-get install -y apt-transport-https ca-certificates curl software-properties-common

Dodajemy klucz danego repozytorium jako zaufany:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add -

Wprowadzamy informacje o repozytorium:

add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

Instalacja Dockera:

apt-get update && apt-get install docker-ce

Przejdźmy teraz do instalacji oprogramowania orkiestracyjnego. Na początek wprowadzamy klucz do repozytoriów:

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -

Teraz informacja o repozytorium:

cat <<EOF >/etc/apt/sources.list.d/kubernetes.list
deb http://apt.kubernetes.io/ kubernetes-xenial main
EOF

Uaktualniamy informacje o pakietach i instalujemy oprogramowanie:

apt-get update
apt-get install -y kubelet kubeadm kubectl

Na głównym węźle naszego klastra dokonujemy edycji pliku "/etc/systemd/system/kubelet.service.d/10-kubeadm.conf" i dopisujemy w nim linijkę z odpowiednim adresem IP:

Environment="KUBELET_EXTRA_ARGS=--cgroup-driver=cgroupfs --node-ip=adres_IP_wezla"

Na węzłach wtórnych postępujemy podobnie tylko linijka z odpowiednim adresem IP ma wyglądać następująco:

Environment="KUBELET_EXTRA_ARGS=--node-ip=adres_IP_wezla" 

Przeładowujemy usługę:

systemctl daemon-reload
systemctl restart kubelet

Jesteśmy gotowi do inicjalizacja klastra, ale wcześniej musimy ustalić jakiej wtyczki do sieci strąków (z ang. "pods") użyjemy. Lista jest dostępna na tej stronie.

Dla tego przykładu wybrano Calico.

Usługa kubelet może jeszcze nie działać, ale nie przejmujemy się tym gdyż teraz przechodzimy do inicjalizacji klastra (na głównym węźle):

root@kubernetes-server0:~# kubeadm init --pod-network-cidr=192.168.0.0/16
[init] Using Kubernetes version: v1.10.0
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks.
    [WARNING SystemVerification]: docker version is greater than the most recently validated version. Docker version: 18.03.0-ce. Max validated version: 17.03
    [WARNING FileExisting-crictl]: crictl not found in system path
Suggestion: go get github.com/kubernetes-incubator/cri-tools/cmd/crictl
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [kubernetes-server0 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.121.122]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [localhost] and IPs [127.0.0.1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [kubernetes-server0] and IPs [192.168.121.122]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests".
[init] This might take a minute or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 52.501186 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[markmaster] Will mark node kubernetes-server0 as master by adding a label and a taint
[markmaster] Master kubernetes-server0 tainted and labelled with key/value: node-role.kubernetes.io/master=""
[bootstraptoken] Using token: 5x7pop.hvg1betp3zxyl0qh
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: kube-dns
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join 192.168.121.122:6443 --token 5x7pop.hvg1betp3zxyl0qh --discovery-token-ca-cert-hash sha256:bd6bc43d0ef54551c0ccfbc48451ae09d3cc46cc8813a5e827e947c40cb59fc9

Jeżeli chcemy używać kubectl jako zwykły użytkownik to (jako dany użytkownik):

mkdir -p $HOME/.kube

Jako root:

cp -i /etc/kubernetes/admin.conf KATALOG_DOMOWY_UŻYTKOWNIKA/.kube/config
chown UŻYTKOWNIK:GRUPA KATALOG_DOMOWY_UŻYTKOWNIKA/.kube/config

Jeżeli chcemy sterować klastrem z poziomu roota to odpalamy

export KUBECONFIG=/etc/kubernetes/admin.conf

Kopiujemy komendę pozwalającą na dołączanie węzłów do klastra. W naszym przypadku jest to

kubeadm join 192.168.121.122:6443 --token 5x7pop.hvg1betp3zxyl0qh --discovery-token-ca-cert-hash sha256:bd6bc43d0ef54551c0ccfbc48451ae09d3cc46cc8813a5e827e947c40cb59fc9

W przypadku jeżeli coś pójdzie nie tak i będziemy chcieli znów zainicjalizować klaster to musimy najpierw pobrać nazwę głównego węzła:

kubectl get nodes

Następnie usuwamy węzeł:

kubectl drain NAZWA_WĘZŁA --delete-local-data --force --ignore-daemonsets
kubectl delete node NAZWA_WĘZŁA

Resetujemy:

kubeadm reset

Jeżeli mamy zainicjalizowany klaster to instalujemy sieć strąków:

kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml

kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml 

Poniższa komenda pokaże nam status konkretnego strąka:

kubectl get pods --all-namespaces

Jeżeli status strąka z przedtrostkiem "kube-dns" będzie ciągle w stanie "Pending" zamiast "Running" musimy sprawdzić co jest powodem przestoju, a robimy to przykładową dla naszego przypadku komendą:

kubectl --namespace=kube-system describe pod kube-dns-86f4d74b45-4rsst

Ze względów bezpieczeństwa domyślnie nie można wdrażać kontenerów na głównym węźle. Jeżeli jednak chcesz to robić to uruchom poniższą komendę:

kubectl taint nodes --all node-role.kubernetes.io/master-

Na każdym z węzłów pracujących uruchamiamy poniższą komendę, która doda je do klastra:

kubeadm join 192.168.121.122:6443 --token 5x7pop.hvg1betp3zxyl0qh --discovery-token-ca-cert-hash sha256:bd6bc43d0ef54551c0ccfbc48451ae09d3cc46cc8813a5e827e947c40cb59fc9

Na głównym węźle sprawdzamy status klastra:

kubectl get nodes

Jeżeli chcemy sterować z innych węzłów musimy skopiować z głównego plik "/etc/kubernetes/admin.conf" i na jednym z hostów uruchomić kubectl jako np.

kubectl --kubeconfig ./admin.conf get nodes

Apache ZooKeeper oraz Apache Kafka w OpenShifcie

Jeżeli nie posiadamy wykupionej lub darmowej usługi OpenShift (Starter lub Pro) to możemy postawić sobie lokalnie własny klaster OpenShift (opis powstał w oparciu o system Ubuntu).

Mając już zainstalowanego Dockera (warto dodać użytkownika do grupy "docker" aby nie trzeba było wykonywać komend dockerowych z prawami roota) sprawdzamy za pomocą komendy (jako root)

sysctl net.ipv4.ip_forward

czy wartością zwracaną jest 1.

Następnie konfigurujemy Dockera aby można było korzystać z niezaufanego Registry lokalnego OpenShifta poprzez edycję pliku "/etc/docker/daemon.json" i dodanie i (lub) aktualizację jak następuje:

{
   "insecure-registries": [
      "172.30.0.0/16"
   ]
}

Po wszystkim wywołujemy (jako root)

systemctl daemon-reload

i

systemctl restart docker

Pobieramy archiwum z narzędziem do zarządzania OpenShiftem:

wget https://github.com/openshift/origin/releases/download/v3.9.0/openshift-origin-client-tools-v3.9.0-191fece-linux-64bit.tar.gz

Rozpakowujemy:

tar -zxvf openshift-origin-client-tools-v3.9.0-191fece-linux-64bit.tar.gz

Kopiujemy (jako root):

cp ./openshift-origin-client-tools-v3.9.0-alpha.3-78ddc10-linux-64bit/oc /usr/bin/

Ustalamy prawa (jako root):

chmod 755 /usr/bin/oc

Stawianie i wyłączanie klastra odbywa się odpowiednio poprzez komendy

oc cluster up

i

oc cluster down

Po postawieniu klastra dostajemy zwrotkę mówiącą pod jakim adresem mamy interfejs oraz dane logowania:

Starting OpenShift using registry.access.redhat.com/openshift3/ose:v3.7.23 ...
OpenShift server started.

The server is accessible via web console at:
    https://127.0.0.1:8443

You are logged in as:
    User:     developer
    Password: <any value>

To login as administrator:
    oc login -u system:admin

Aby mieć możliwość pełnej administracji (m.in. dostęp do wszystkich projektów i zarządzanie różnego rodzaju politykami) musimy (jako root) najpierw zalogować się do OpenShifta:

oc login -u admin -p admin

Następnie (jako root):

oc adm policy add-cluster-role-to-user cluster-admin system --config=/var/lib/origin/openshift.local.config/master/admin.kubeconfig

Wychodzimy z konta roota i wchodzimy na stronę z OpenShiftem. W moim przypadku jest to "https://127.0.0.1:8443/". Logujemy się jako "system" i hasło "admin".

Zalogować się do naszej platformy możemy również za pomocą tokena. Na stronie OpenShifta wprowadzamy login i hasło, a następnie po pomyślnym uwierzytelnieniu prawym górnym rogu klikamy na ikonę użytkownika i wybieramy "Copy Login Command" i zawartość schowka wklejamy do terminala aby się zalogować jak np.:

oc login https://127.0.0.1:8443 --token=6TmPUCncEyzqXglh3goioYJSBasTGb7thS-vyaXIoVU

Możemy się również zalogować wpisując

oc login -u system -p admin

Sprawdźmy jakie mamy projekty:

oc get project

Następnie używamy konkretnego projektu:

oc project nazwa_projektu

lub tworzymy nowy projekt:

oc new-project kafka

Warto zaznaczyć aby na każdym etapie tworzenia poszczególnych zasobów w OpenShifcie sprawdzać czy nie wystąpiły jakieś błędy.

Nazwa projektu musi się zgadzać z opcją "namespace" w plikach konfiguracyjnych jeżeli takowa występuje.

Przechowywanie danych w klastrze jest obsługiwane przez tworzenie ze źródeł obiektów PersistentVolume. Dostęp do nich możesz uzyskać rozszcząc sobie prawa do zasobu poprzez wysłanie żądania (ze specjalnymi atrybutami jak np. rozmiar magazynu z danymi) przy użyciu obiektu PersistentVolumeClaim. Pomiędzymi tymi dwoma obiektami istnieje proces, który dopasowuje żądanie z dostępnym wolumenem i wiąże je ze sobą.

PersistentVolume reprezentuje część istniejącego sieciowego miejsca do przechowywania danych w klastrze, który został postawiony przez administratora. Z kolei PersistentVolumeClaim reprezentuje żądanie użytkownika o przydzielenia miejsca. Innymi słowy tak jak strąk (z ang. "pod") konsumuje zasoby węzła tak PersistenceVolumeClaim konsumuje zasoby PersistentVolume.

Tworzymy plik "kafka_pvc.yml" z definicją obiektów PersistentVolumeClaim dla Kafki:

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-kafka-0
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-kafka-1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-kafka-2
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-kafka-3
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-kafka-4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Wprowadzamy komendę, która utworzy nam magazyny danych:

oc create -f kafka_pvc.yml

Następnie plik "zookeeper_pvc.yml" dla ZooKeepera:

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-zoo-0
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-zoo-1
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: datadir-zoo-2
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Odpowiednio podajemy komendę:

oc create -f zookeeper_pvc.yml

Aby sprawdzić jakie mamy dostępne wolumeny wpisujemy:

oc get pvc

Przechodzimy do wdrażania naszych usług, które w Kubernetesie obsługiwane są jako wewnętrzne równoważenie obciążenia (z ang. "internal load balancer"). Można zdefiniować zestaw zreplikowanych strąków ("pods") i wtedy pośredniczyć w przekazywaniu do nich połączeń. Usługi mają przypisany adres IP oraz port, za pomocą którego przekazuje się połączenia do odpowiedniego strąka.

Rekomendowana maksymalna liczba strąków na węzeł OpenShifta to 110.

Tworzymy plik "zookeeper_services.yml" o zawartości:

apiVersion: v1
kind: Service
metadata:
  name: zookeeper
spec:
  ports:
  - port: 2181
    name: client
  selector:
    app: zk
---
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
  name: zk
  labels:
    app: zk
spec:
  ports:
  - port: 2888
    name: peer
  - port: 3888
    name: leader-election
  clusterIP: None
  selector:
    app: zk

Odpalamy tworzenie usług jako:

oc create -f zookeeper_services.yml

StatefulSet jest obiektem używanym do zarządzania aplikacjami stanowymi; wdrażaniem i skalowaniem zestawem strąków.

Kolejnym punktem jest wpisanie do pliku "zookeeper_cluster.yml" następujących danych:

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: zoo
spec:
  serviceName: "zk"
  replicas: 3
  template:
    metadata:
      labels:
        app: zk
      annotations:
        pod.alpha.kubernetes.io/initialized: "true"
        pod.alpha.kubernetes.io/init-containers: '[
            {
                "name": "install",
                "image": "gcr.io/google_containers/zookeeper-install:0.1",
                "imagePullPolicy": "Always",
                "args": ["--version=3.5.2-alpha", "--install-into=/opt", "--work-dir=/work-dir"],
                "volumeMounts": [
                    {
                        "name": "opt",
                        "mountPath": "/opt/"
                    },
                    {
                        "name": "workdir",
                        "mountPath": "/work-dir"
                    }
                ]
            },
            {
                "name": "bootstrap",
                "image": "java:openjdk-8-jre",
                "command": ["/work-dir/peer-finder"],
                "args": ["-on-start=\"/work-dir/on-start.sh\"", "-service=zk"],
                "env": [
                  {
                      "name": "POD_NAMESPACE",
                      "valueFrom": {
                          "fieldRef": {
                              "apiVersion": "v1",
                              "fieldPath": "metadata.namespace"
                          }
                      }
                   }
                ],
                "volumeMounts": [
                    {
                        "name": "opt",
                        "mountPath": "/opt/"
                    },
                    {
                        "name": "workdir",
                        "mountPath": "/work-dir"
                    },
                    {
                        "name": "datadir",
                        "mountPath": "/tmp/zookeeper"
                    }
                ]
            }
        ]'
    spec:
      containers:
      - name: zk
        image: java:openjdk-8-jre
        ports:
        - containerPort: 2181
          name: client
        - containerPort: 2888
          name: peer
        - containerPort: 3888
          name: leader-election
        command:
        - /opt/zookeeper/bin/zkServer.sh
        args:
        - start-foreground
        readinessProbe:
          exec:
            command:
            - sh
            - -c
            - "/opt/zookeeper/bin/zkCli.sh ls /"
          initialDelaySeconds: 15
          timeoutSeconds: 5
        volumeMounts:
        - name: datadir
          mountPath: /tmp/zookeeper
        - name: opt
          mountPath: /opt/
      volumes:
      - name: opt
        emptyDir: {}
      - name: workdir
        emptyDir: {}
  volumeClaimTemplates:
  - metadata:
      name: datadir
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 20Gi

Odpalamy jako aby stworzyć StatefulSet "zoo":

oc create -f zookeeper_cluster.yml

Przechodzimy do wdrażania Kafki. Zaczniemy od wprowadzenia poniższych danych do pliku "kafka_broker_service.yml":

---
apiVersion: v1
kind: Service
metadata:
  annotations:
    service.alpha.kubernetes.io/tolerate-unready-endpoints: "true"
  name: broker
spec:
  ports:
  - port: 9092
  clusterIP: None
  selector:
    app: kafka

Odpalamy jako:

oc create -f kafka_broker_service.yml

Każdy z brokerów, do których możemy się podłączyć aby wysyłać wiadomości będzie dostępny pod nazwą hosta według wzoru "kafka-NUMER_WĘZŁA.broker.kafka.svc.cluster.local".

Kolejną rzeczą jest następna usługa, której definicję wrzucamy do pliku "kafka_service.yml":

---
apiVersion: v1
kind: Service
metadata:
  name: kafka
spec:
  ports:
  - port: 9092
  selector:
    app: kafka 

Wprowadzamy komendę:

oc create -f kafka_service.yml

Na koniec definicja klastra Kafki w pliku "kafka_cluster.yml":

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: kafka
spec:
  serviceName: "broker"
  replicas: 3
  template:
    metadata:
      labels:
        app: kafka
      annotations:
        pod.alpha.kubernetes.io/initialized: "true"
        pod.alpha.kubernetes.io/init-containers: '[
        ]'
    spec:
      containers:
      - name: broker
        image: solsson/kafka:0.10.0.1
        ports:
        - containerPort: 9092
        command:
        - sh
        - -c
        - "./bin/kafka-server-start.sh config/server.properties --override broker.id=$(hostname | awk -F'-' '{print $2}')"
        volumeMounts:
        - name: datadir
          mountPath: /opt/kafka/data
  volumeClaimTemplates:
  - metadata:
      name: datadir
      annotations:
        volume.alpha.kubernetes.io/storage-class: anything
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 100Mi

Ostatecznie wprowadzamy:

oc create -f kafka_cluster.yml

Teraz musimy sobie przetestować nasze wdrożenia. W tym celu tworzymy nowy strąk ("pod") definiując go w pliku "kafka_client_pod.yml":

apiVersion: v1
kind: Pod
metadata:
  name: testclient
spec:
  containers:
  - name: kafka
    image: solsson/kafka:0.10.0.1
    command:
      - sh
      - -c
      - "exec tail -f /dev/null"

I odpalamy:

oc create -f kafka_client_pod.yml

Na dwóch oddzielnych terminalach odpalamy komendy umożliwiające nad zalogowanie się do osobnych sesji w kontenerach do testów:

oc rsh testclient

W pierwszym terminalu tworzymy temat w ZooKeeperze:

./bin/kafka-topics.sh --zookeeper zookeeper:2181 --create --partitions 1 --replication-factor 3 --topic test

W tym samym terminalu podłączamy się do ZooKeepera aby konsumować wiadomości:

./bin/kafka-console-consumer.sh --zookeeper zookeeper:2181 --topic test --from-beginning

Na drugim terminalu wpisujemy:

./bin/kafka-console-producer.sh --broker-list kafka-0.broker.kafka.svc.cluster.local:9092,kafka-1.broker.kafka.svc.cluster.local:9092,kafka-2.broker.kafka.svc.cluster.local:9092 --topic test

i wprowadzamy jakikolwiek ciąg znaków, który powinien pojawić się nam w pierwszym terminalu.

Aby usunąć wszystkie strąki ("pody"), usługi i klastry to wpisujemy:

oc delete all --all

Dodatkowo usuwamy wszystkie wolumeny:

oc delete pvc --all

Cassandra - kopie zapasowe

Tworzenie kopii zapasowych w Cassandrze polega na wykonywaniu migawek wszystkich plików z danymi (pliki SSTable). Możesz zrobić migawkę wszystkich przestrzeni kluczy (z ang. "keyspaces") lub pojedyńczej.

Migawkę tworzymy komendą

nodetool snapshot

lub

 nodetool -h adres_serwera -p numer_portu snapshot

Powyższe komendy utworzą migawki wszystkich przestrzeni kluczy. Jeżeli chcemy zrobić migawkę konkretnej przestrzeni to wpisujemy:

nodetool snapshot nazwa_przestrzeni_kluczy

Po wykonaniu komendy podany zostanie nam numer migawki.

Dane kopii (pliki o rozszerzeniu "db") znajdziemy w "katalog_Cassandry/data/nazwa_przestrzeni_kluczy/nazwa_tabeli/snapshots/numer_migawki".

Poprzednie kopie nie są usuwane więc warto przedtem wywołać

nodetool snapshot clearsnapshot

lub

nodetool snapshot clearsnapshot nazwa_przestrzeni_kluczy

Przywracanie danych wymaga wszystkich plików migawek dla tabeli, a jeżeli używane są inkrementowane kopie zapasowe to wszystkie pliki inkrementowanych kopii zapasowych utworzone po tym jak wykonana została migawka.

Generalnie przed przystąpieniem do przywracania danch powinno się usunąć wszystkie dane z tabeli i ustawić odpowiednią konsystencję:

truncate nazwa_przestrzeni_klucz.nazwa_tabeli;
consistency all;

Cassandra może przywracać dane kiedy istnieje schemat tabel. Jeżeli tego nie zrobiłeś to możesz albo:
- przywrócić dane z migawki,
- ponownie stworzyć schemat
lub:
- stworzyć ponownie schemat,
- przywrócić migawkę,
- uruchomić "nodetool refresh".

Aby przywrócić dane do konkretnej tabeli należy:
1) wyłączyć Cassandrę,
2) usunąć wszystkie pliki z "katalog_Cassandry/commitlog",
3) usunąć wszystkie pliki o rozszerzeniu "db" z "katalog_Cassandry/data/nazwa_przestrzeni_kluczy/nazwa_tabeli",
4) skopiować zawartość katalogu "katalog_Cassandry/data/nazwa_przestrzeni_kluczy/nazwa_tabeli/snapshots/numer_migawki" do "katalog_Cassandry/data/nazwa_przestrzeni_kluczy/nazwa_tabeli" i zmienić właściciela oraz grupę na odpowiednie dla serwera Cassandry (zwykle jest to "cassandra" i "cassandra"),
5) włączyć Cassandrę.

W celu automatyzacji powyższych zadań stworzone zostało narzędzie Carmela.

Logi w RAM-ie

Aby przedłużyć żywotność karty używanej jako dysk w Raspberry Pi warto przechowywać logi w pamięci RAM. Aby to zrobić do "/etc/fstab" dodajemy następujący wpis:

tmpfs /var/log tmpfs defaults,noatime,nosuid,mode=0755,size=100m 0 0

MongoDB - użytkownicy

Po zainstalowaniu serwera MongoDB warto zabezpieczyć instancję poprzez dodanie użytkowników administrujących serwerem i włączyć uwierzytelnianie.

Poniższa procedura dodaje użytkownika, który może administrować innymi użytkownikami w bazie (upewnij się wcześniej czy już takowy nie istnieje):

use admin;
db.createUser( { user: "siteUserAdmin", pwd: "haslo", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } );

Kolejny użytkownik może np. włączać serwer i tworzyć inne bazy:

use admin;db.createUser( { user: "siteRootAdmin", pwd: "haslo", roles: [ { role:  "root", db: "admin" } ] } );

Następnie do pliku konfiguracyjnego serwera dodajemy:

 security:
authorization: enabled

Aby uwierzytelnianie zadziałało musimy zrestartować serwer.

Teraz możemy zalogować się na dwa sposoby:
- "mongo --username uzytkownik --password haslo --authenticationDatabase nazwa_bazy",
- wywolujemy w powloce komende "mongo", a następnie:

 use nazwa_bazy;
db.auth("uzytkownik", "haslo");

Przystępując do procesu tworzenia nowych użytkowników należy najpierw stworzyć użytkownika administrującego systemem, a potem z jego poziomu tworzyć innych użytkowników.

Rola stworzona w bazie danych "admin" może zawierać przywileje, które mają zastosowanie do bazy danych "admin", innych baz lub zasobów klastra.

MongoDB - kopie zapasowe i odzyskiwanie danych

W MongoDB możemy tworzyć kopie zapasowe poprzez utworzenie migawki lub stosując dedykowane do tego narzędzia.

Jeżeli chodzi o tworzenie migawki bazowych plików z danymi to musimy mieć w pliku konfiguracyjnym włączone księgowanie (z ang. "journaling"):

storage:

   journal:

      enabled: true

Dziennik zaś musi być umieszczony na tym samym logicznym wolumenie co pliki z danymi bazy. Jeżeli system nie wspiera księgowania to możesz zastosować zwykłe kopiowanie danych, ale uprzednio zastopuj wszystkie operacje zapisu do bazy.

Jeżeli chcesz stworzyć migawkę to musisz zatrzymać usługę MongoDB, a przywracanie z niej wartości nadpisuje wszystkie istniejące dane.

Jeżeli chodzi o inną metodę aniżeli migawka to stosujemy tutaj narzędzia mongodump i mongorestore.

mongodump domyślnie tworzy kopię w katalogu "dump", którym znajdują się pliki z nazwą w formacie "nazwa_bazy.bson".

Podstawowe wywołanie umożliwiające zapis w konkretnym katalogu to:
"mongodump --out nazwa_katalogu".

Możemy dokonać zrzutu konkretnej bazy:
"mongodump --db nazwa_bazy"
lub konkretnej kolekcji:
"mongodump --db nazwa_bazy --collection nazwa_kolekcji".

Jeżeli chcemy dokonać archiwizacji plików kopii w locie to stosujemy wywołanie jak np:
"mongodump --collection nazwa_kolekcji --db nazwa_bazy --gzip --archive=nazwa_pliku.gz".

Przywracanie danych w podstawowej postaci wygląda jak następuje (opcja "-d" jest konieczna od wersji 3 MongoDB):
"mongorestore -d nazwa_bazy_do_ktorej_chcemy_przywrocic_dane katalog_ze_zrzutem_bazy".

Jeżeli chcemy usunąć inne kolekcje aniżeli te, które są w kopii zapasowej to stosujemy wywołanie:
"mongorestore katalog_ze_zrzutem_bazy --drop".

Chcąc odzyskać konkretną kolekcję wprowadzamy w linii poleceń:
"mongorestore --db nazwa_bazy_do_ktorej_chcemy_przywrocic --collection nazwa_kolekcji katalog_ze_zrzutem_bazy/nazwa_bazy/nazwa_kolekcji.bson".

Jeżeli w docelowym serwerze nie ma bazy, która jest określona przez opcję "--db" to narzędzie ją utworzy.

Przywracanie z archiwum odbywa się identycznie jak tworzenie kopii tj.:
"mongorestore --db nazwa_bazy_do_ktorej_chcemy_przywrocic --gzip --archive=nazwa_pliku.gz".

mongorestore pozwala tylko na wprowadzanie danych, a nie na uaktualnienie czy scalanie. Jeżeli istniejące dane posiadają ten sam identyfikator w docelowej bazie to nie zostaną one podmienione.

Jeżeli posiadasz uwierzytelnianie to do wywołania mongodump lub mongorestore musisz dodać:
"--username nazwa_uzytkownika --password haslo --authenticationDatabase nazwa_bazy".