One place for hosting & domains

      Ubuntu

      How To Use Telepresence on Kubernetes for Rapid Development on Ubuntu 20.04


      The author selected the Tech Education Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      Application developers building microservices on Kubernetes often encounter two major problems that slow them down:

      • Slow feedback loops. Once a code change is made, it must be deployed to Kubernetes to be tested. This requires a container build, push to a container registry, and deployment to Kubernetes. This adds minutes to every code iteration.
      • Insufficient memory and CPU locally. Developers attempt to speed up the feedback loop by running Kubernetes locally with minikube or the equivalent. However, resource-hungry applications quickly exceed the compute and memory available locally.

      Telepresence is a Cloud-Native Computing Foundation project for fast, efficient development on Kubernetes. With Telepresence, you run your service locally, while you run the rest of your application in the cloud. Telepresence creates a bi-directional network connection between your Kubernetes cluster and your local workstation. This way, the service you’re running locally can communicate with services in the cluster, and vice versa. That allows you to use the compute and memory resources of the cluster, but without having to go through a complete deployment cycle for each change.

      In this tutorial, you’ll configure Telepresence on your local machine running Ubuntu 20.04 to work with a Kubernetes cluster. You’ll intercept traffic to your cluster and redirect it to your local environment.

      To complete this tutorial, you will need:

      Step 1 — Installing Telepresence

      In this step, you’ll install Telepresence and connect it to your Kubernetes cluster. First, make sure that you have kubectl configured and that you can connect to your Kubernetes cluster from your local workstation. Use the get services command to check your cluster’s status:

      The output will look like this, with your own cluster’s IP address listed:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 116m

      Next you’ll install Telepresence locally. Telepresence comes as a single binary.

      Use curl to download the latest binary for Linux (around 50 MB):

      • sudo curl -fL https://app.getambassador.io/download/tel2/linux/amd64/latest/telepresence -o /usr/local/bin/telepresence

      Then use chmod to make the binary executable:

      • sudo chmod a+x /usr/local/bin/telepresence

      Now that you have Telepresence installed locally, you can verify that it worked by connecting to your Kubernetes cluster:

      You’ll see the following output:

      Output

      Launching Telepresence Daemon ... Connected to context default (https://<cluster public IP>)

      If Telepresence doesn’t connect, check your kubectl configuration.

      Verify that Telepresence is working properly by connecting to the Kubernetes API server with the status command:

      You will see the following output. Telepresence Proxy: ON indicates that Telepresence has configured a proxy to access services on the cluster.

      Output

      Root Daemon: Running Version : v2.1.4 (api 3) Primary DNS : "" Fallback DNS: "" User Daemon: Running Version : v2.1.4 (api 3) Ambassador Cloud : Logged out Status : Connected Kubernetes server : https://7c10e553-10d1-4fee-9b7d-1ccbce4cdd34.k8s.ondigitalocean.com Kubernetes context: <your_kubernetes_context> Telepresence proxy: ON (networking to the cluster is enabled) Intercepts : 0 total Connected Context: do-tor1-k8s-bg-telepresence (https://bee66877-1b07-4bb1-8c8f-4fd62e416865.k8s.ondigitalocean.com) Proxy: ON (networking to the cluster is enabled) Intercepts: 0 total

      When you use telepresence connect, on the server side, Telepresence creates a namespace called ambassador and runs a traffic manager. On the client side, Telepresence sets up DNS to enable local access to remote servers. That means you do not have to use kubectl port-forward to manually configure access to local services. When you access a remote service the DNS resolves to a specific IP address. For more details, see the Telepresence architecture documentation.

      You can now connect to the remote Kubernetes cluster from your local workstation, as if the Kubernetes cluster were running on your laptop. Next you’ll try out a sample application.

      Step 2 — Adding a Sample Node.js Application

      In this step, you’ll use a simple Node.js application to simulate a complex service running on your Kubernetes cluster. Instead of creating the file locally, you’ll access it from DockerHub and deploy it to your cluster from there. The file is called hello-node, and returns a text string:

      var http = require('http');
      
      var handleRequest = function(request, response) {
        console.log('Received request for URL: ' + request.url);
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello, Node!');
        response.end();
      };
      
      http.createServer(handleRequest).listen(9001);
      console.log('Use curl <hostname>:9001 to access this server...');
      

      Use the kubectl create deployment command to create a deployment called hello node:

      • kubectl create deployment hello-node --image=docommunity/hello-node:1.0

      You will see the following output:

      Output

      deployment.apps/hello-node created

      Use the get pod command to confirm that the deployment has occurred and the app is now running on the cluster:

      The output will show a READY status of 1/1.

      Output

      NAME READY STATUS RESTARTS AGE hello-node-86b49779bf-9zqvn 1/1 Running 0 11s

      Use the expose deployment command to make the application available on port 9001:

      • kubectl expose deployment hello-node --type=LoadBalancer --port=9001

      The output will look like this:

      Output

      service/hello-node exposed

      Use the kubectl get svc command to check that the load balancer is running:

      The output will look like this, with your own IP addresses:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE hello-node LoadBalancer 10.245.75.48 <pending> 9001:30682/TCP 4s kubernetes ClusterIP 10.245.0.1 <none> 443/TCP 6d

      If you are using local Kubernetes without load balancer support, then the external IP value for LoadBalancer will show as <pending> permanently. That is fine for the purposes of this tutorial. If you are using DigitalOcean Kubernetes, you should see the external IP value will display the IP address after a delay.

      Next, verify that the application is running by using curl to access the load balancer:

      If you’re not running a load balancer, you can use curl to access the service directly:

      • curl <servicename>.<namespace>:9001

      The output will look like this:

      Output

      Hello, Node!

      Next, use the telepresence connect command to connect Telepresence to the cluster:

      This allows you to access all remote services as if they were local, so you can access the service by name:

      • curl hello-node.default:9001

      You’ll receive the same response as you did when you accessed the service via its IP:

      Output

      Hello, Node!

      The service is up and running on the cluster, and you can access it remotely. If you make any changes to the hello-node.js app, you’d need to take the following steps:

      • Modify the app.
      • Rebuild the container image.
      • Push it to a container registry.
      • Deploy to Kubernetes.

      That is a lot of steps. You could use tooling (automated pipelines, such as Skaffold) to reduce the manual work. But the steps themselves cannot be bypassed.

      Now you’ll build another version of our hello-node app, and use Telepresence to test it without having to build the container image or push it to registry or even deploy to Kubernetes.

      Step 3 — Running a New Version of the Service Locally

      In this step, you’ll modify the existing hello-node application on your local machine. You’ll then use Telepresence to route traffic to the local version with a Telepresence intercept. The intercept takes traffic intended for your cluster and reroutes it to your local version of the service, so you can continue working in your development environment.

      Create a new file containing a modified version of the sample application:

      Add the following code to the new file:

      hello-node-v2.js

      var http = require('http');
      
      var handleRequest = function(request, response) {
        console.log('Received request for URL: ' + request.url);
        response.writeHead(200, {'Content-Type': 'text/plain'});
        response.write('Hello, Node V2!');
        response.end();
      };
      
      http.createServer(handleRequest).listen(9001);
      

      Save and exit the file.

      Start the service with Node:

      Leave the service running, then open a new terminal window and access the service:

      The output will look like this:

      Output

      Hello, Node V2!

      This service is only running locally, however. If you try to access the remote server, it is currently running version 1 of hello-node. To fix that, you’ll enable an intercept to route all traffic going to the hello-node service in the cluster to the local version of the service.

      Use the intercept command to set up the intercept:

      • telepresence intercept hello-node --port 9001

      The output will look like this:

      Output

      Using deployment hello-node intercepted Intercept name : hello-node State : ACTIVE Destination : 127.0.0.1:9001 Volume Mount Error: sshfs is not installed on your local machine Intercepting : all TCP connections

      Check that the intercept has been set up correctly with the status command:

      The output will look like this:

      Output

      Root Daemon: Running Version : v2.1.4 (api 3) Primary DNS : "" Fallback DNS: "" User Daemon: Running Version : v2.1.4 (api 3) Ambassador Cloud : Logged out Status : Connected Kubernetes server : https://7c10e553-10d1-4fee-9b7d-1ccbce4cdd34.k8s.ondigitalocean.com Kubernetes context: <your_kubernetes_context> Telepresence proxy: ON (networking to the cluster is enabled) Intercepts : 1 total hello-node: brian@telepresence-tutorial

      Now access the remote service with curl as you did previously:

      The output will look like this:

      Output

      Hello, Node V2!

      Now, any messages sent to the service on the cluster are redirected to the local service. This is useful in the development stage, because you can avoid the deployment loop (build, push, deploy) for every individual change to your code.

      Conclusion

      In this tutorial, you’ve installed Telepresence on your local machine, and demonstrated how to make code changes in your local environment without having to deploy to Kubernetes every time you make a change. For more tutorials and information about Telepresence, see the Telepresence documentation.



      Source link

      How To Deploy a Static HTML Website with Ansible on Ubuntu 20.04 (Nginx)



      Part of the Series:
      How To Write Ansible Playbooks

      Ansible is a modern configuration management tool that doesn’t require the use of an agent software on remote nodes, using only SSH and Python to communicate and execute commands on managed servers. This series will walk you through the main Ansible features that you can use to write playbooks for server automation. At the end, we’ll see a practical example of how to create a playbook to automate setting up a remote Nginx web server and deploy a static HTML website to it.

      If you were following along with all parts of this series, at this point you should be familiar with installing system packages, applying templates, and using handlers in Ansible playbooks. In this part of the series, you’ll use what you’ve seen so far to create a playbook that automates setting up a remote Nginx server to host a static HTML website on Ubuntu 20.04.

      Start by creating a new directory on your Ansible control node where you’ll set up the Ansible files and a demo static HTML website to be deployed to your remote server. This could be in any location of your choice within your home folder. In this example we’ll use ~/ansible-nginx-demo.

      • mkdir ~/ansible-nginx-demo
      • cd ~/ansible-nginx-demo

      Next, copy your existing inventory file into the new directory. In this example, we’ll use the same inventory you set up at the beginning of this series:

      • cp ~/ansible-practice/inventory .

      This will copy a file named inventory from a folder named ansible-practice in your home directory, and save it to the current directory.

      Obtaining the Demo Website

      For this demonstration, we’ll use a static HTML website that is the subject of our How To Code in HTML series. Start by downloading the demo website files by running the following command:

      • curl -L https://github.com/do-community/html_demo_site/archive/refs/heads/main.zip -o html_demo.zip

      You’ll need unzip to unpack the contents of this download. To make sure you have this tool installed, run:

      Then, unpack the demo website files with:

      This will create a new directory called html_demo_site-main on your current working directory. You can check the contents of the directory with an ls -la command:

      • ls -la html_demo_site-main

      Output

      total 28 drwxrwxr-x 3 sammy sammy 4096 sep 18 2020 . drwxrwxr-x 5 sammy sammy 4096 mrt 25 15:03 .. -rw-rw-r-- 1 sammy sammy 1289 sep 18 2020 about.html drwxrwxr-x 2 sammy sammy 4096 sep 18 2020 images -rw-rw-r-- 1 sammy sammy 2455 sep 18 2020 index.html -rw-rw-r-- 1 sammy sammy 1079 sep 18 2020 LICENSE -rw-rw-r-- 1 sammy sammy 675 sep 18 2020 README.md

      Creating a Template for Nginx’s Configuration

      You’ll now set up the Nginx template that is necessary to configure the remote web server. Create a new folder within your ansible-demo directory to hold non-playbook files:

      Then, open a new file called nginx.conf.j2:

      This template file contains an Nginx server block configuration for a static HTML website. It uses three variables: document_root, app_root, and server_name. We’ll define these variables later on when creating the playbook. Copy the following content to your template file:

      ~/ansible-nginx-demo/files/nginx.conf.j2

      server {
        listen 80;
      
        root {{ document_root }}/{{ app_root }};
        index index.html index.htm;
      
        server_name {{ server_name }};
      
        location / {
         default_type "text/html";
         try_files $uri.html $uri $uri/ =404;
        }
      }
      

      Save and close the file when you’re done.

      Creating a New Ansible Playbook

      Next, we’ll create a new Ansible playbook and set up the variables that we’ve used in the previous section of this guide. Open a new file named playbook.yml:

      This playbook starts with the hosts definition set to all and a become directive that tells Ansible to run all tasks as the root user by default (the same as manually running commands with sudo). Within this playbook’s var section, we’ll create three variables: server_name, document_root, and app_root. These variables are used in the Nginx configuration template to set up the domain name or IP address that this web server will respond to, and the full path to where the website files are located on the server. For this demo, we’ll use the ansible_default_ipv4.address fact variable because it contains the remote server’s public IP address, but you can replace this value with your server’s hostname in case it has a domain name properly configured within a DNS service to point to this server:

      ~/ansible-nginx-demo/playbook.yml

      ---
      - hosts: all
        become: yes
        vars:
          server_name: "{{ ansible_default_ipv4.address }}"
          document_root: /var/www/html
          app_root: html_demo_site-main
        tasks:
      

      You can keep this file open for now. The next sections will walk you through all tasks that you’ll need to include in this playbook to make it fully functional.

      Installing Required Packages

      The following task will update the apt cache and then install the nginx package on remote nodes:

      ~/ansible-nginx-demo/playbook.yml

      . . .
          - name: Update apt cache and install Nginx
            apt:
              name: nginx
              state: latest
              update_cache: yes
      

      Uploading Website Files to Remote Nodes

      The next task will use the copy built-in module to upload the website files to the remote document root. We’ll use the document_root variable to set the destination on the server where the application folder should be created.

      ~/ansible-nginx-demo/playbook.yml

      . . .
          - name: Copy website files to the server's document root
            copy:
              src: "{{ app_root }}"
              dest: "{{ document_root }}"
              mode: preserve
      

      Applying and Enabling the Custom Nginx Configuration

      We’ll now apply the Nginx template that will configure the web server to host your static HTML file. After the configuration file is set at /etc/nginx/sites-available, we’ll create a symbolic link to that file inside /etc/nginx-sites-enabled and notify the Nginx service for a posterior restart. The entire process will require two separate tasks:

      ~/ansible-nginx-demo/playbook.yml

      . . .
          - name: Apply Nginx template
            template:
              src: files/nginx.conf.j2
              dest: /etc/nginx/sites-available/default
            notify: Restart Nginx
      
          - name: Enable new site
            file:
              src: /etc/nginx/sites-available/default
              dest: /etc/nginx/sites-enabled/default
              state: link
            notify: Restart Nginx
      

      Allowing Port 80 on UFW

      Next, include the task that enables tcp access on port 80:

      ~/ansible-nginx-demo/playbook.yml

      . . .
          - name: Allow all access to tcp port 80
            ufw:
              rule: allow
              port: '80'
              proto: tcp
      . . .
      

      Creating a Handler for the Nginx Service

      To finish this playbook, the only thing left to do is to set up the Restart Nginx handler:

      ~/ansible-nginx-demo/playbook.yml

      . . .
        handlers:
          - name: Restart Nginx
            service:
              name: nginx
              state: restarted  
      

      Running the Finished Playbook

      Once you’re finished including all the required tasks in your playbook file, it will look like this:

      ~/ansible-nginx-demo/playbook.yml

      ---
      - hosts: all
        become: yes
        vars:
          server_name: "{{ ansible_default_ipv4.address }}"
          document_root: /var/www
          app_root: html_demo_site-main
        tasks:
          - name: Update apt cache and install Nginx
            apt:
              name: nginx
              state: latest
              update_cache: yes
      
          - name: Copy website files to the server's document root
            copy:
              src: "{{ app_root }}"
              dest: "{{ document_root }}"
              mode: preserve
      
          - name: Apply Nginx template
            template:
              src: files/nginx.conf.j2
              dest: /etc/nginx/sites-available/default
            notify: Restart Nginx
      
          - name: Enable new site
            file:
              src: /etc/nginx/sites-available/default
              dest: /etc/nginx/sites-enabled/default
              state: link
            notify: Restart Nginx
      
          - name: Allow all access to tcp port 80
            ufw:
              rule: allow
              port: '80'
              proto: tcp
      
        handlers:
          - name: Restart Nginx
            service:
              name: nginx
              state: restarted
      

      To execute this playbook on the server(s) that you set up in your inventory file, run ansible-playbook with the same connection arguments you’ve used when running a connection test within the introduction of this series. Here, we’ll be using an inventory file named inventory and the sammy user to connect to the remote server. Because the playbook requires sudo to run, we’re also including the -K argument to provide the remote user’s sudo password when prompted by Ansible:

      • ansible-playbook -i inventory playbook.yml -u sammy -K

      You’ll see output like this:

      Output

      BECOME password: PLAY [all] ********************************************************************************************** TASK [Gathering Facts] ********************************************************************************** ok: [203.0.113.10] TASK [Update apt cache and install Nginx] *************************************************************** ok: [203.0.113.10] TASK [Copy website files to the server's document root] ************************************************* changed: [203.0.113.10] TASK [Apply Nginx template] ***************************************************************************** changed: [203.0.113.10] TASK [Enable new site] ********************************************************************************** ok: [203.0.113.10] TASK [Allow all access to tcp port 80] ****************************************************************** ok: [203.0.113.10] RUNNING HANDLER [Restart Nginx] ************************************************************************* changed: [203.0.113.10] PLAY RECAP ********************************************************************************************** 203.0.113.10 : ok=7 changed=3 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

      Once the playbook is finished, if you go to your browser and access your server’s hostname or IP address you should now see the following page:

      HTML Demo Site Deployed by Ansible

      Congratulations, you have successfully automated the deployment of a static HTML website to a remote Nginx server, using Ansible.

      If you make changes to any of the files in the demo website, you can run the playbook again and the copy task will make sure any file changes are reflected in the remote host. Because Ansible has an idempotent behavior, running the playbook multiple times will not trigger changes that were already made to the system.



      Source link

      So sichern, wiederherstellen und migrieren Sie eine MongoDB-Datenbank unter Ubuntu 20.04


      Der Autor hat den COVID-19 Relief Fund dazu ausgewählt, eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      MongoDB ist eine der beliebtesten NoSQL-Datenbank-Engines. Es ist bekannt für seine Skalierbarkeit, Robustheit, Zuverlässigkeit und Benutzerfreundlichkeit. In diesem Artikel werden Sie eine Beispiel-MongoDB-Datenbank sichern, wiederherstellen und migrieren.

      Beim Importieren und Exportieren einer Datenbank werden Daten in einem für Menschen lesbaren Format verarbeitet, das mit anderen Softwareprodukten kompatibel ist. Im Gegensatz dazu erstellen oder verwenden die Sicherungs- und Wiederherstellungsvorgänge von MongoDB MongoDB-spezifische Binärdaten, wodurch nicht nur die Konsistenz und Integrität Ihrer Daten, sondern auch die spezifischen MongoDB-Attribute erhalten bleiben. Daher ist es für die Migration normalerweise vorzuziehen, Backup und Wiederherstellung zu verwenden, solange das Quell- und das Zielsystem kompatibel sind.

      Voraussetzungen

      Bevor Sie diesem Tutorial folgen, stellen Sie bitte sicher, dass Sie die folgenden Voraussetzungen erfüllen:

      Sofern nicht anders angegeben, sollten alle Befehle, für die in diesem Tutorial-Root-Berechtigungen erforderlich sind, als Nicht-Root-Benutzer mit Sudo-Berechtigungen ausgeführt werden.

      Schritt 1 — Verwenden von JSON und BSON in MongoDB

      Bevor Sie mit diesem Artikel fortfahren, ist ein grundlegendes Verständnis der Angelegenheit erforderlich. Wenn Sie Erfahrung mit anderen NoSQL-Datenbanksystemen wie Redis haben, können Sie bei der Arbeit mit MongoDB einige Ähnlichkeiten feststellen.

      MongoDB verwendet die Formate JSON und BSON (binäres JSON) zum Speichern seiner Informationen. JSON ist das für Menschen lesbare Format, das sich perfekt zum Exportieren und eventuell zum Importieren Ihrer Daten eignet. Sie können Ihre exportierten Daten mit jedem Tool, das JSON unterstützt, einschließlich eines einfachen Texteditors, weiter verwalten.

      Ein Beispiel-JSON-Dokument sieht folgendermaßen aus:

      Example of JSON Format

      {"address":[
          {"building":"1007", "street":"Park Ave"},
          {"building":"1008", "street":"New Ave"},
      ]}
      

      JSON ist zum Arbeiten praktisch, unterstützt jedoch nicht alle in BSON verfügbaren Datentypen. Dies bedeutet, dass es bei Verwendung von JSON zu einem sogenannten „Verlust der Wiedergabetreue“ der Informationen kommt. Zum Sichern und Wiederherstellen ist es besser, das binäre BSON zu verwenden.

      Zweitens müssen Sie sich nicht um die explizite Erstellung einer MongoDB-Datenbank kümmern. Wenn die für den Import angegebene Datenbank noch nicht vorhanden ist, wird sie automatisch erstellt. Noch besser ist die Struktur der Sammlungen (Datenbanktabellen). Im Gegensatz zu anderen Datenbank-Engines wird in MongoDB die Struktur beim Einfügen des ersten Dokuments (Datenbankzeile) automatisch neu erstellt.

      Drittens kann das Lesen oder Einfügen großer Datenmengen, wie z. B. die Aufgaben dieses Artikels, in MongoDB ressourcenintensiv sein und einen Großteil Ihrer CPU, Ihres Arbeitsspeichers und Ihres Speicherplatzes beanspruchen. Dies ist entscheidend, da MongoDB häufig für große Datenbanken und Big Data verwendet wird. Die einfachste Lösung für dieses Problem besteht darin, die Exporte und Sicherungen während der Nacht oder außerhalb der Stoßzeiten auszuführen.

      Viertens kann die Informationskonsistenz problematisch sein, wenn Sie einen ausgelasteten MongoDB-Server haben, auf dem sich die Informationen während des Datenbankexports oder -sicherungsprozesses ändern. Eine mögliche Lösung für dieses Problem ist die Replikation, die Sie möglicherweise in Betracht ziehen, wenn Sie mit dem Thema MongoDB fortfahren.

      Während Sie die Import- und Exportfunktionen zum Sichern und Wiederherstellen Ihrer Daten verwenden können, gibt es bessere Möglichkeiten, um die vollständige Integrität Ihrer MongoDB-Datenbanken sicherzustellen. Um Ihre Daten zu sichern, sollten Sie den Befehl mongodump verwenden. Zum Wiederherstellen verwenden Sie mongorestore. Sehen wir uns an, wie sie funktionieren.

      Schritt 2 – Verwenden von mongodump zum Sichern einer MongoDB-Datenbank

      Lassen Sie uns zuerst das Sichern Ihrer MongoDB-Datenbank behandeln.

      Ein wesentliches Argument für mongodump ist --db, das den Namen der Datenbank angibt, die Sie sichern möchten. Wenn Sie keinen Datenbanknamen angeben, sichert mongodump alle Ihre Datenbanken. Das zweite wichtige Argument ist --out, das das Verzeichnis definiert, in das die Daten gespeichert werden. Lassen Sie uns beispielsweise die newdb-Datenbank sichern und im Verzeichnis /var/backups/mongobackups speichern. Im Idealfall haben wir jedes unserer Backups in einem Verzeichnis mit dem aktuellen Datum wie /var/backups/mongobackups/10-29-20.

      Erstellen Sie zuerst dieses Verzeichnis /var/backups/mongobackups:

      • sudo mkdir /var/backups/mongobackups

      Führen Sie dann mongodump aus:

      • sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"`

      Sie werden eine Ausgabe wie diese sehen:

      Output

      2020-10-29T19:22:36.886+0000 writing newdb.restaurants to 2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)

      Beachten Sie, dass wir im obigen Verzeichnispfad das Datum + „%m-%d-%y“ verwendet haben, das automatisch das aktuelle Datum abruft. Auf diese Weise können wir Backups im Verzeichnis wie /var/backups/10-29-20/ erstellen. Dies ist besonders praktisch, wenn wir die Backups automatisieren.

      An diesem Punkt verfügen Sie über eine vollständige Sicherung der newdb-Datenbank im Verzeichnis /var/backups/mongobackups/10-29-20/newdb/. Dieses Backup verfügt über alles, um newdb richtig zu restaurieren und ihre sogenannte „Treue“ zu erhalten.

      In der Regel sollten Sie regelmäßige Sicherungen durchführen, vorzugsweise wenn der Server am wenigsten ausgelastet ist. Auf diese Weise können Sie den Befehl mongodump als Cron-Job festlegen, sodass er regelmäßig ausgeführt wird, z. B. jeden Tag um 03:03 Uhr.

      Um dies zu erreichen, öffnen Sie Crontab, Cron’s Editor:

      Beachten Sie, dass Sie beim Ausführen von sudo crontab die Cron-Jobs für den Root-Benutzer bearbeiten. Dies wird empfohlen, da die Crons für Ihren Benutzer möglicherweise nicht ordnungsgemäß ausgeführt werden, insbesondere wenn für Ihr Sudo-Profil eine Passwortüberprüfung erforderlich ist.

      Fügen Sie in die Crontab-Eingabeaufforderung den folgenden mongodump-Befehl ein:

      crontab

      3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"`
      

      Im obigen Befehl lassen wir das Argument --db absichtlich weg, da Sie typischerweise alle Ihre Datenbanken gesichert werden möchten.

      Abhängig von Ihrer MongoDB-Datenbankgröße wird Ihnen möglicherweise bald der Speicherplatz mit zu vielen Backups ausgehen. Aus diesem Grund wird auch empfohlen, die alten Backups regelmäßig zu bereinigen oder zu komprimieren.

      Um beispielsweise alle Backups zu löschen, die älter als sieben Tage sind, können Sie den folgenden Bash-Befehl verwenden:

      • find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;

      Ähnlich wie beim vorherigen mongodump-Befehl können Sie diesen auch als Cron-Job hinzufügen. Er sollte kurz vor dem Start des nächsten Backups ausgeführt werden, z. B. um 03:01 Uhr. Öffnen Sie zu diesem Zweck crontab erneut:

      Fügen Sie danach die folgende Zeile ein:

      crontab

      1 3 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} ;
      

      Speichern und schließen Sie die Datei.

      Wenn Sie alle Aufgaben in diesem Schritt ausführen, wird eine ordnungsgemäße Backup-Lösung für Ihre MongoDB-Datenbanken sichergestellt.

      Schritt 3 – Verwenden von mongorestore zum Wiederherstellen und Migrieren einer MongoDB-Datenbank

      Wenn Sie Ihre MongoDB-Datenbank aus einem früheren Backup wiederherstellen, wird die genaue Kopie Ihrer MongoDB-Informationen zu einem bestimmten Zeitpunkt erstellt, einschließlich aller Indizes und Datentypen. Dies ist besonders nützlich, wenn Sie Ihre MongoDB-Datenbanken migrieren möchten. Zum Wiederherstellen von MongoDB verwenden wir den Befehl mongorestore, der mit den binären Backups funktioniert, die mongodump produziert.

      Lassen Sie uns unsere Beispiele mit der newdb-Datenbank fortsetzen und sehen, wie wir sie aus dem zuvor erstellten Backup wiederherstellen können. Wir geben zuerst den Namen der Datenbank mit dem Argument --nsInclude an. Wir verwenden newdb.* zum Wiederherstellen aller Sammlungen. Um eine einzelne Sammlung wie Restaurants wiederherzustellen, verwenden Sie stattdessen newdb.restaurants.

      Wenn wir dann --drop verwenden, stellen wir sicher, dass die Zieldatenbank zuerst weggelassen wird, sodass das Backup in einer sauberen Datenbank wiederhergestellt wird. Als letztes Argument geben wir das Verzeichnis des letzten Backups an, das in etwa so aussieht: /var/backups/mongobackups/10-29-20/newdb/.

      Sobald Sie ein zeitgestempeltes Backup haben, können Sie dieses mit folgendem Befehl wiederherstellen:

      • sudo mongorestore --db newdb --drop /var/backups/mongobackups/10-29-20/newdb/

      Sie werden eine Ausgabe wie diese sehen:

      Output

      2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead 2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir 2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json 2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson 2020-10-29T19:25:46.130+0000 no indexes to restore 2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents) 2020-10-29T19:25:46.130+0000 done

      Im obigen Fall stellen wir die Daten auf demselben Server wieder her, auf dem wir das Backup erstellt haben. Wenn Sie die Daten auf einen anderen Server migrieren und dieselbe Technik verwenden möchten, sollten Sie das Backup-Verzeichnis, in unserem Fall /var/backups/mongobackups/10-29-20/newdb/, auf den anderen Server kopieren.

      Zusammenfassung

      Sie haben jetzt einige wichtige Aufgaben im Zusammenhang mit dem Sichern, Wiederherstellen und Migrieren Ihrer MongoDB-Datenbanken ausgeführt. Kein Produktions-MongoDB-Server sollte jemals ohne eine zuverlässige Backup-Strategie wie die hier beschriebene ausgeführt werden.



      Source link