Allas-objektitallennuksen käyttö Rahdissa

Lisätietoja itse palvelusta on Allas -sivulla.

Varmuuskopiointi Altaaseen

Rahdista voi tehdä varmuuskopioita Altaaseen eri tavoilla. Näytämme kaksi esimerkkiä:

Ensimmäisessä käytetään toista Podia kopioimaan PersistentVolumen sisältö Altaaseen.
Toinen on bash-skripti, joka sinun täytyy suorittaa omalta paikalliselta koneeltasi.

Ensimmäisessä esimerkissä otamme käyttöön nginx-deploymentin, joka käyttää PersistentVolumeClaimia. Tarjoamme tiedostot testaustarkoituksiin.

NGINX-deploymentin valmistelu

Ensin rakennamme ja otamme käyttöön NGINX-palvelimen tätä ohjetta varten.

Koska tavallista nginx-imagea ei voi käyttää Rahdissa, rakennamme oman imagen tällä Dockerfilellä:

FROM nginx:stable

ENV LISTEN_PORT=8080

# support running as arbitrary user which belongs to the root group
RUN chmod g+rwx /var/cache/nginx /var/run /var/log/nginx

# users are not allowed to listen on privileged ports
RUN sed -i.bak "s/listen\(.*\)80;/listen ${LISTEN_PORT};/" /etc/nginx/conf.d/default.conf

# comment out the user directive, as the master process runs as an arbitrary user in OKD anyway
RUN sed -i.bak 's/^user/#user/' /etc/nginx/nginx.conf

EXPOSE 8080

Jos rakennat imagen paikallisesti, muista puskea se projektiisi ja tarvittaessa muuntaa se amd64-arkkitehtuurille.

Tämän jälkeen voit ottaa tämän nginx-palvelimen käyttöön ja julkaista sen tällä Deploymentilla:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: <custom_nginx_image>
        resources:
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
          - containerPort: 8080
        volumeMounts:
        - name: myvol
          mountPath: /mnt
      volumes:
      - name: myvol
        persistentVolumeClaim:
          claimName: nginx-pvc

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  ports:
  - port: 8080

---
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: nginx-route
spec:
  host: ""
  path: /
  to:
    kind: Service
    name: nginx-svc
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: edge

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nginx-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: standard-csi

Deployment käyttää tässä esimerkissä PersistentVolumeClaimia. Tallenna tiedosto ja ota se käyttöön tällä komennolla: oc apply -f {name_of_yaml_file}.

Nyt kun nginx-Podimme on käynnissä, haluamme kopioida PVC:n sisällön Altaaseen. Käytämme tähän uutta deploymentia, jossa on rclone Docker image.

Ensimmäinen esimerkki: toisen Podin käyttö

Luo rclone.conf, johon lisäät access_key_id- ja secret_access_key-arvosi.

Jos sinulla ei ole access_key_id- ja secret_access_key -arvoja, sinun täytyy ensin sourceta Pouta-projektisi ja käyttää sitten tätä komentoa tunnistetietojen luomiseen:

openstack ec2 credentials create

Kun tunnistetiedot on luotu, luo rclone.conf-tiedosto:

[default]
type = s3
provider = Other
env_auth = false
access_key_id = {ACCESS_KEY_ID}
secret_access_key = {SECRET_ACCESS_KEY}
endpoint = a3s.fi
acl = private

Korvaa {ACCESS_KEY_ID} ja {SECRET_ACCESS_KEY} omilla tunnistetiedoillasi.

Luo rclone.sh-skripti:

#!/bin/sh -e

rclone copy "/mnt/" "default:{BUCKET}"

echo "Done!"

Korvaa {BUCKET} kohdeämpärillä, johon haluat varmuuskopioida tiedostosi.

Tämän jälkeen sinun täytyy luoda oma mukautettu rclone Docker image:

FROM rclone/rclone

COPY rclone.conf /.rclone.conf
COPY rclone.sh /usr/local/bin/
RUN chmod 755 /.rclone.conf
RUN chmod +x /usr/local/bin/rclone.sh

Jos luot imagen paikallisesti, muista puskea se projektiisi.

Kun kaikki tämä on tehty, voit ottaa käyttöön rclone-Podisi. Voit käyttää tätä esimerkkiä:

apiVersion: v1
kind: Pod
metadata:
  name: rclone
spec:
  containers:
  - name: copys3
    image: <your_rclone_image>
    command: ["/usr/local/bin/rclone.sh"]
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"
    volumeMounts:
    - name: vol-to-backup
      mountPath: /mnt/
  volumes:
  - name: vol-to-backup
    persistentVolumeClaim:
      claimName: nginx-pvc # Must match the PVC name that you want to back up

Tallenna tiedosto ja käytä tätä komentoa: oc apply -f {name_of_yaml_file}.

Warning

Jos PersistentVolumeClaimisi on ReadWriteOnce, sinun täytyy skaalata nginx-deployment alas, jotta rclonea ajava Pod voi liittää taltion. Käytä tätä komentoa:

oc scale --replicas=0 deploy/nginx

Pod käynnistyy ja varmuuskopioi PVC:si sisällön Altaaseen. Muista skaalata alkuperäinen deploymentisi takaisin ylös (oc scale --replicas=1 deploy/nginx) kopioinnin valmistuttua.

Tällä ratkaisulla on etuja ja haittoja:

Edut:

Aja Podia omassa Rahti-projektissasi.

Haitat:

Jos PVC on ReadWriteOnce, käyttökatko on välttämätön.

Toinen esimerkki: bash-skriptin käyttö

Jotta seuraava skripti toimisi, oletamme, että rclone-komentoriviohjelma on asennettu ja että Allas-ämpäri on luotu. rclone.conf-tiedoston tulee olla määritetty paikallisessa järjestelmässäsi kuten on selitetty kohdassa rclonen määrittäminen. Allas-ämpärin voi luoda myös rclonella, kuten on kuvattu kohdassa rclonen käyttö Allaksen kanssa.

Tämä skripti varmuuskopioi Rahdissa käyttöönotetun sovelluksen. Esimerkissä oletetaan, että sovellus liittää datansa polkuun /backup, eli /backup on volumeMounts-määrityksen mountPath.

#!/usr/bin/env bash

# Set your pod name, source directory, and destination directory
if [[ -z $1 ]];
then
    echo "No Podname parameter passed."
    exit 22
else
     echo "The POD_NAME = $1 is set."
fi

POD_NAME=$1
SOURCE_DIR="/backup"
TIMESTAMP=$(date '+%Y%m%d%H%M%S') # Generate a timestamp
DEST_DIR="/tmp/pvc_backup_$TIMESTAMP.tar.gz" # Include the timestamp in the filename
RCLONE_CONFIG_PATH="your/path/to/rclone.conf"
S3_BUCKET="pvc-test-allas" # Your bucket name

# Echo function to display task messages
echo_task() {
  echo "$(date '+%Y-%m-%d %H:%M:%S') - $1"
}

# Function to handle errors
handle_error() {
  echo_task "Error: $1"
  exit 1
}

# Check if the pod exists
oc get pod "$POD_NAME" &>/dev/null
if [ $? -ne 0 ]; then
  echo_task "Pod $POD_NAME not found. Aborting backup."
  exit 1
fi

# Create a tar archive within the pod
echo_task "Creating a tar archive within the pod..."
oc exec "$POD_NAME" -- /bin/sh -c "tar -czf /tmp/pvc_backup.tar.gz -C $SOURCE_DIR ."
if [ $? -ne 0 ]; then
  handle_error "Failed to create a tar archive in the pod. Aborting backup."
fi

# Copy the tar archive to the local machine
echo_task "Copying the tar archive to the local machine..."
oc cp "$POD_NAME:/tmp/pvc_backup.tar.gz" "$DEST_DIR"
if [ $? -ne 0 ]; then
  handle_error "Failed to copy the tar archive to the local machine. Aborting backup."
fi
echo_task "Backup completed successfully. The archive is stored in $DEST_DIR."

# Use Rclone to copy the tarball to S3
echo_task "Copying the tarball to S3..."
rclone --config "$RCLONE_CONFIG_PATH" copy "$DEST_DIR" default:"$S3_BUCKET"
if [ $? -ne 0 ]; then
  handle_error "Failed to upload tarball to S3"
fi
echo_task "Backup completed successfully. The archive is stored in $S3_BUCKET/$(basename "$DEST_DIR")"

exit 0

Jos haluat siivota tar-arkistotiedostot, voit lisätä seuraavat komennot sen jälkeen, kun arkisto on tallennettu Altaaseen.

# Clean up the tar archive in the pod
oc exec "$POD_NAME" -- /bin/sh -c "rm /tmp/pvc_backup.tar.gz"

# Clean up the local temporary files, either every archive
rm -rf /tmp/pvc_backup*

# or only the archive created by this run
rm "$DEST_DIR"

Skriptin voi suorittaa seuraavasti olettaen, että skriptin nimi on push_to_allas.sh ja että se on suoritettava:

./push_to_allas.sh "mypod-vol"

Tällä ratkaisulla on etuja ja haittoja:

Edut:

Yksinkertaisuus: käsittelet taltiota käytännössä kuten mitä tahansa muuta hakemistoa. Datan kopioiminen hakemistosta Altaaseen on suoraviivaista.
Joustavuus: voit valita liitoksesta tietyt tiedostot tai hakemistot kopioitavaksi Altaaseen, mikä sopii hyvin pienille tiedostoille.

Haitat:

Suorituskyky: tämä menetelmä voi olla hitaampi, erityisesti jos taltiossa on suuri määrä tiedostoja.

Tallennuksen suorituskyky

Allaksen käytössä suorituskyvyn kannalta on otettava huomioon useita seikkoja:

Pienet I/O-operaatiot voivat heikentää tallennuksen suorituskykyä merkittävästi. Samalla kokonaiskoolla yksi suuri tiedosto on nopeampi kuin suuri määrä pieniä tiedostoja. Yksinkertainen ratkaisu voi olla kerätä kaikki pienet tiedostot yhteen arkistotiedostoon, kuten tar-tiedostoon.
Koska tallennuspooli on jaettu, viive voi vaihdella. Jaettu laitteisto tarkoittaa jaettua suorituskykyä eri käyttäjien kesken.
Yksisäikeinen I/O on hidasta; monisäikeistä I/O:ta kannattaa käyttää aina kun mahdollista.