-
Konfigurointi
-
Objektitallennustila
Allas-tallennus Rahtissa
Lisätietoja Altaasta
Varmuuskopiointi Altaaseen
Rahtista voi tehdä varmuuskopioita Altaaseen eri tavoilla. Näytämme kaksi esimerkkiä: - Ensimmäisessä käytetään toista podia kopioimaan persistentin taltion sisältö Altaaseen. - Toisessa käytetään bash-skriptiä, joka suoritetaan omalta paikalliselta koneelta.
Tätä ensimmäistä esimerkkiä varten otamme käyttöön nginx-deploymentin, joka käyttää PersistentVolumeClaim-resurssia. Tarjoamme tiedostot testaustarkoituksiin.
NGINX-deploymentin valmistelu
Ensin rakennamme ja otamme käyttöön NGINX-palvelimen tätä ohjetta varten.
Rakennamme nginx-imagemme tällä Dockerfilellä: (koska tavallista nginx-imagea ei voi käyttää OpenShiftissä)
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 user directive as master process is run as user in OpenShift anyhow
RUN sed -i.bak 's/^user/#user/' /etc/nginx/nginx.conf
EXPOSE 8080
Jos rakennat imagen paikallisesti, älä unohda ladata sitä projektisi rekisteriin.
Voit ottaa tämän nginx-palvelimen käyttöön 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: <our_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
Tallenna tiedosto ja ota se käyttöön tällä komennolla: oc apply -f {name_of_yaml_file}
Deployment käyttää tässä esimerkissä PersistentVolumeClaim-resurssia.
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äminen
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 source-komennolla ottaa Pouta-projektisi käyttöön ja sitten luoda tunnistetiedot tällä komennolla:
Kun tunnistetiedot on luotu, tee 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:
Korvaa {BUCKET} kohdeämpärillä, johon haluat varmuuskopioida tiedostosi.
Sen 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
Kun tämä kaikki 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 backup
Tallenna tiedosto ja käytä tätä komentoa: oc apply -f {name_of_yaml_file}.
Warning
Jos PersistentVolumeClaim-resurssisi on ReadWriteOnce, sinun täytyy skaalata nginx-deployment alas, jotta rclonea ajava podi voi liittää taltion.
Käytä tätä komentoa: oc scale --replicas=0 deploy/nginx
Jos PersistentVolumeClaim-resurssisi on ReadWriteMany, deploymentia ei tarvitse skaalata alas.
Voit tarkistaa asian tällä komennolla: oc get pvc. Näet joko RWO tai RWX.
Podi suoritetaan ja varmuuskopioi PVC:si sisällön Altaaseen. Älä unohda skaalata alkuperäistä deploymentiasi takaisin ylös (oc scale --replicas=1 deploy/nginx) kopioinnin valmistuttua.
Tässä ratkaisussa on HYVIÄ ja HUONOJA puolia:
Hyvät puolet:
- Suoritat podin omassa Rahti-projektissasi
Huonot puolet:
- PVC on
ReadWriteOnce, joten käyttökatko on välttämätön.
Toinen esimerkki: bash-skriptin käyttäminen
Jotta seuraava skripti toimisi, oletamme, että rclone-komentoriviohjelma on asennettu ja Allas-ämpärin nimi on luotu. rclone.conf tulee olla asetettuna paikallisessa järjestelmässäsi yllä olevan esimerkin mukaisesti. Esimerkiksi rclone.conf-polku voi sijaita paikassa ~/.config/rclone/rclone.conf. Lisätietoja Allas-ämpärin luomisesta. Tämä skripti varmuuskopioi Rahtissa käyttöönotetun sovelluksen. Sovelluksella on esimerkiksi nimi /backup volumeMounts-määrityksen mountPath-arvona.
#!/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 sync the tarball to S3
echo_task "Syncing the tarball to S3..."
rclone --config "$RCLONE_CONFIG_PATH" sync "$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$DEST_DIR"
exit 0
Jos sinun täytyy siivota tar-arkistotiedostot, voit lisätä seuraavan skriptin sen jälkeen, kun tiedostot on ladattu Altaaseen.
# Clean up the tar archive in the pod
oc exec "$POD_NAME" -- /bin/sh -c "rm /tmp/pvc_backup.tar.gz"
# Clean up temporary files
rm -rf /tmp/pvc_backup*
or
rm "$DEST_DIR"
push_to_allas.sh ja että se on suoritettava:
Tässä ratkaisussa on HYVIÄ ja HUONOJA puolia:
Hyvät puolet:
- 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, ja ratkaisu sopii hyvin pienikokoisille tiedostoille.
Huonot puolet:
- Suorituskyky: tämä menetelmä voi olla hitaampi, erityisesti jos taltiossa on suuri määrä tiedostoja.
Tallennuksen suorituskyky
Allasta käytettäessä suorituskyvyn kannalta on otettava huomioon useita asioita:
- Pieni io heikentää tallennuksen suorituskykyä. Samalla kokonaiskoolla yksi suuri tiedosto on nopeampi kuin joukko pieniä tiedostoja. Ratkaisuna voi olla kaikkien pienten tiedostojen kokoaminen yhdeksi arkistotiedostoksi, kuten
tar-tiedostoksi. - Koska tallennuspooli on jaettu, viive voi vaihdella. Jaettu laitteisto tarkoittaa käyttäjien kesken jaettua suorituskykyä.
- Yksisäikeinen io on hidasta, joten monisäikeistä io:ta kannattaa käyttää aina kun mahdollista.