One place for hosting & domains

      Usando

      Cómo instalar y configurar una pila LEMP usando Software Collections en CentOS 7


      El autor seleccionó la Apache Software Foundation para recibir una donación de $100 como parte del programa Write for DOnations.

      Introducción

      Una pila de software LEMP es un grupo de software de código abierto que se instala normalmente en conjunto para permitir que un servidor hospede sitios web dinámicos y aplicaciones web. Este término es realmente un acrónimo que representa el sistema operativo de Linux y el servidor web de ENginx (que sustituye al componente Apache de una pila LAMP). Los datos del sitio se almacenan en una base de datos de MySQL (utilizando MariaDB) y el contenido dinámico se procesa mediante PHP.

      Los componentes de pilas LEMP a veces se instalan usando el repositorio de EPEL de CentOS 7. Sin embargo, este repositorio contiene paquetes obsoletos. Por ejemplo, no puede instalar ninguna versión de PHP superior a la 5.4.16 desde EPEL, aunque no exista soporte para esta versión desde hace mucho tiempo. Para obtener las versiones más recientes del software, se recomienda que utilice Software Collections, también conocido como “SCLs”. Las SCL son recopilaciones de recursos para desarrolladores proporcionadas por RedHat que le permiten usar varias versiones de software en el mismo sistema sin afectar paquetes previamente instalados.

      En esta guía, instalará una pila LEMP en un servidor de CentOS 7. El sistema operativo CentOS se ocupa del componente Linux. Instalará el resto de los componentes usando el repositorio de Software Collections y luego podrá configurarlos para una página web simple.

      Requisitos previos

      Antes de iniciar este tutorial, debe configurar el servidor de CentOS 7 siguiendo la guía de configuración inicial del servidor de CentOS 7 e incluir un usuario sudo no root.

      Paso 1: Habilitación del repositorio de Software Collections

      Si desea obtener acceso a SCLs para CentOS, instale el archivo de versión de Linux Software Collections de CentOS:

      • sudo yum install centos-release-scl

      Consulte la lista de paquetes SCL disponibles usando el siguiente comando:

      • yum --disablerepo='*' --enablerepo='centos-sclo-rh' --enablerepo='centos-sclo-sclo' list available

      Para evitar conflictos en todo el sistema, los paquetes SCL se instalan en el directorio /opt/rh. Esto le permite, por ejemplo, instalar Python 3.5 en una máquina con CentOS 7 sin eliminar Python 2.7 ni interferir con su funcionamiento.

      Todos los archivos de configuración para paquetes de SCLs se almacenan en el directorio correspondiente dentro del directorio /etc/opt/rh/. Los paquetes de SCLs proporcionan scripts de shell que definen las variables de entorno necesarias para usar las aplicaciones incluidas. Por ejemplo, PATH, LD_LIBRARY_PATH y MANPATH. Estos scripts se almacenan en el sistema de archivos como /opt/rh/nombre del paquete/enable.

      Con esto, estará listo para comenzar a instalar los paquetes indicados en esta guía.

      Paso 2: Instalación del servidor web Nginx

      Para mostrar páginas web a los visitantes vamos a emplear Nginx, un servidor web moderno y eficiente.

      Instale Nginx usando el siguiente comando yum. Asegúrese de sustituir el valor resaltado por la versión de Nginx que desee instalar; el número más alto en el nombre del paquete corresponderá a la versión más reciente (112 en el momento en que se redactó este artículo):

      • sudo yum install rh-nginx112

      Una vez terminada la instalación, inicie el servicio Nginx:

      • sudo systemctl start rh-nginx112-nginx

      Confirme que Nginx esté en ejecución ingresando el comando systemctl status:

      • sudo systemctl status rh-nginx112-nginx

      Output

      ● rh-nginx112-nginx.service - The nginx HTTP and reverse proxy server Loaded: loaded (/usr/lib/systemd/system/rh-nginx112-nginx.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2018-03-19 15:15:43 UTC; 1min 17s ago Main PID: 10556 (nginx) CGroup: /system.slice/rh-nginx112-nginx.service ├─10556 nginx: master process /opt/rh/rh-nginx112/root/usr/sbin/nginx ├─10557 nginx: worker process └─10558 nginx: worker process Mar 19 15:15:43 lemp-centos-222 systemd[1]: Starting The nginx HTTP and reverse proxy server... Mar 19 15:15:43 lemp-centos-222 nginx-scl-helper[10541]: nginx: the configuration file /etc/opt/rh/rh-nginx... ok Mar 19 15:15:43 lemp-centos-222 nginx-scl-helper[10541]: nginx: configuration file /etc/opt/rh/rh-nginx112/...ful Mar 19 15:15:43 lemp-centos-222 systemd[1]: Started The nginx HTTP and reverse proxy server. Hint: Some lines were ellipsized, use -l to show in full.

      En este momento, su servidor podría estar expuesto a accesos por parte de usuarios no autorizados. Para corregir esto, configure un firewall usando firewalld. Quizá necesite instalar primero firewalld. Puede hacerlo con el siguiente comando:

      • sudo yum install firewalld

      Luego, inicie el servicio firewalld:

      • sudo systemctl start firewalld

      A continuación, añada algunas reglas de firewall para permitir el acceso de SSH a su servidor y conexiones HTTP y HTTPS con Nginx:

      • sudo firewall-cmd --permanent --add-service=ssh
      • sudo firewall-cmd --zone=public --permanent --add-service=http
      • sudo firewall-cmd --zone=public --permanent --add-service=https

      Vuelva a cargar firewalld para implementar las nuevas reglas de firewall:

      • sudo firewall-cmd --reload

      Encontrará más información sobre firewalld en la sección Cómo configurar un firewall usando FirewallD en CentOS 7.

      Una vez agregadas estas nuevas reglas, podrá probar si el servidor se encuentra en ejecución accediendo al nombre de dominio o a la dirección IP pública de su servidor en su navegador web.

      Si no tiene un nombre de dominio para su servidor y no conoce la dirección IP pública de este, puede encontrarla escribiendo lo siguiente en su terminal:

      Escriba la dirección IP resultante en la barra de dirección de su navegador web. Con esto, deberá poder ver la página de inicio predeterminada de Nginx:

      http://server_domain_or_IP
      

      Página predeterminada de Nginx

      Si ve esta página, significa que instaló Nginx correctamente. Antes de continuar, habilite Nginx para que comience a funcionar en el inicio usando el siguiente comando:

      • sudo systemctl enable rh-nginx112-nginx

      El servidor Nginx ya está instalado. Ahora puede proceder a instalar el software de base de datos MariaDB.

      Paso 3: Instalación de MariaDB para gestionar datos de sitios

      Ahora que contamos con un servidor web, es el momento de instalar MariaDB, un reemplazo a medida de MySQL, para almacenar y administrar los datos de su sitio.

      Instale MariaDB con el comando que se muestra a continuación. Una vez más, reemplace el valor señalado por el número de versión que desee instalar; el número más alto corresponde a la versión más reciente disponible (102, en el momento en que se redactó este artículo):

      • sudo yum install rh-mariadb102

      Una vez que se complete la instalación, inicie el servicio MariaDB con el siguiente comando:

      • sudo systemctl start rh-mariadb102-mariadb

      Con esto, MariaDB quedará instalado y en funcionamiento. No obstante, faltará completar su configuración.

      Para proteger la instalación, MariaDB incorpora un script de seguridad que solicita modificar algunos ajustes no seguros predeterminados. Ejecute el script escribiendo lo siguiente:

      • source /opt/rh/rh-mariadb102/enable
      • mysql_secure_installation

      El mensaje solicitará su contraseña root actual. Puesto que acaba de instalar MySQL, es probable que no disponga de una. Podrá dejar el campo en blanco presionando ENTER. Luego se le preguntará si desea configurar una contraseña root. Introduzca Y y siga las instrucciones:

      . . .
      Enter current password for root (enter for none):
      OK, successfully used password, moving on...
      
      Setting the root password ensures that nobody can log into the MariaDB
      root user without the proper authorization.
      
      Set root password? [Y/n] Y
      New password: password
      Re-enter new password: password
      Password updated successfully!
      Reloading privilege tables..
       ... Success!
      . . .
      

      Para el resto de las preguntas, presione la tecla ENTER en cada mensaje para aceptar los valores predeterminados. Con esto, se eliminarán algunos usuarios anónimos y la base de datos de prueba, se deshabilitarán las credenciales de inicio de sesión remoto de root y se cargarán estas nuevas reglas para que MariaDB aplique de inmediato los cambios que realizamos.

      Lo último que se debe hacer aquí es habilitar MariaDB para que se ejecute en el inicio. Utilice el siguiente comando para hacerlo:

      • sudo systemctl enable rh-mariadb102-mariadb

      En este punto, su sistema de base de datos estará configurado y podrá proceder a configurar PHP en su servidor.

      Paso 4: Instalación y configuración de PHP para procesamiento

      Ya tiene instalados Nginx para sus páginas y MariaDB para el almacenamiento y la administración de sus datos. Sin embargo, aún le falta instalar una herramienta que pueda generar contenido dinámico. Es el momento de PHP.

      Dado que Nginx no contiene procesamiento PHP nativo como otros servidores web, deberá instalar php-fpm, que significa “administrador de proceso de fastCGI”. Más adelante, configurará Nginx para que transmita solicitudes PHP a este software para su procesamiento.

      Instale este módulo y también use un paquete helper que permitirá la comunicación de PHP con el backend de su base de datos. La instalación extraerá los archivos principales de PHP necesarios. Podrá ejecutarla escribiendo lo siguiente:

      • sudo yum install rh-php71-php-fpm rh-php71-php-mysqlnd

      De esta manera, sus componentes PHP quedarán instalados. Sin embargo, existe un ligero cambio de configuración que debería realizar para reforzar la seguridad de su configuración.

      Abra el archivo de configuración de php.ini principal con privilegios root:

      • sudo vi /etc/opt/rh/rh-php71/php.ini

      En este archivo, busque el parámetro que configura cgi.fix_pathinfo. Este se comentará con un punto y coma (;) y se fijará en “1” por defecto.

      Este ajuste es extremadamente inseguro porque indica a PHP que intente ejecutar el archivo más cercano que pueda encontrar si no se puede hallar el archivo PHP solicitado. Básicamente, esto permitiría a los usuarios realizar solicitudes PHP de una forma que haría posible la ejecución scripts que no deberían poder ejecutar.

      Cambie ambas condiciones eliminando los comentarios de la línea y fijando su valor en “0”, como se muestra aquí:

      71/php.ini’>/etc/opt/rh/rh-php71/php.ini

      cgi.fix_pathinfo=0
      

      Guarde y cierre el archivo cuando termine (presione ESC, ingrese :wq y luego presione Enter).

      A continuación, abra el archivo de configuración de php-fpm www.conf:

      • sudo vi /etc/opt/rh/rh-php71/php-fpm.d/www.conf

      Por defecto, este archivo está configurado para usarse con el servidor Apache. Dado que su servidor tiene Nginx instalado, encuentre las líneas que configuran user y group y cambie sus valores de “apache” a “nginx”:

      71/php-fpm.d/www.conf’>/etc/opt/rh/rh-php71/php-fpm.d/www.conf

      user = nginx
      group = nginx
      

      Luego, guarde y cierre el archivo.

      A continuación, inicie su procesador PHP escribiendo lo siguiente:

      • sudo systemctl start rh-php71-php-fpm

      Luego habilite php-fpm para que se ejecute en el inicio:

      • sudo systemctl enable rh-php71-php-fpm

      Con esto, PHP quedará correctamente instalado en su servidor. Sin embargo, deberá configurarlo para complementarse con el otro software que instaló, de modo que su servidor funcione correctamente con el contenido de su sitio.

      Paso 5: Configuración de Nginx para usar el procesador PHP

      En este punto, ya tendrá instalados todos los componentes requeridos de una pila LEMP. En el nivel de la configuración, el único cambio que aún debe hacer es indicarle a Nginx que utilice su procesador PHP para contenido dinámico.

      Este cambio de configuración se realiza en el nivel de bloque del servidor (los bloques de servidor son similares a los hosts virtuales de Apache). Abra el archivo predeterminado de configuración de bloques del servidor Nginx escribiendo lo siguiente:

      • sudo vi /etc/opt/rh/rh-nginx112/nginx/nginx.conf

      Elimine los comentarios del bloque de ubicación ~ .php$ (el segmento del archivo que se ocupa de las solicitudes PHP, que se encuentra dentro del bloque del server) y su contenido borrando los símbolos de numeral (#) del principio de cada línea. También debe actualizar la opción fastcgi_param a SCRIPT FILENAME $document_root$fastcgi_script_name. Esto informa a PHP sobre la ubicación de la raíz del documento donde puede encontrar archivos para procesar.

      Una vez realizados los cambios necesarios, el bloque del server tendrá este aspecto:

      /etc/nginx/sites-available/default

      ...
      server {
          listen       80 default_server;
          listen       [::]:80 default_server;
          server_name  _;
          root         /opt/rh/rh-nginx112/root/usr/share/nginx/html;
      
          # Load configuration files for the default server block.
          include      /etc/opt/rh/rh-nginx112/nginx/default.d/*.conf;
      
          location / {
          }
      
          error_page 404 /404.html;
          location = /40x.html {
          }
      
          error_page 500 502 503 504  /50x.html;
          location = /50x.html {
          }
      
          # proxy the PHP scripts to Apache listening on 127.0.0.1:80
          #
          #location ~ .php$ {
          #    proxy_pass   http://127.0.0.1;
          #}
      
          # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
          #
          location ~ .php$ {
              root           html;
              fastcgi_pass   127.0.0.1:9000;
              fastcgi_index  index.php;
              fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
              include        fastcgi_params;
          }
      
          # deny access to .htaccess files, if Apache's document root
          # concurs with nginx's one
          #
          #location ~ /.ht {
          #    deny  all;
          #}
      }
      ...
      

      Cuando realice los cambios, podrá guardar el archivo y salir del editor.

      A continuación, pruebe someta a prueba su archivo de configuración en busca de errores de sintaxis ejecutando los siguientes comandos:

      • source /opt/rh/rh-nginx112/enable
      • sudo nginx -t

      Si se notifica algún error, vuelva a revisar su archivo antes de continuar.

      Una vez que su archivo de configuración sea válido, vuelva a cargar Nginx para implementar los cambios que realizó:

      • sudo systemctl reload rh-nginx112-nginx

      Ahora que Nginx, PHP y MariaDB se han instalado y configurado, solo queda confirmar que la configuración de pila LEMP pueda facilitar correctamente el contenido a los visitantes de su sitio.

      Paso 6: Creación de un archivo PHP para probar la configuración

      Su pila LEMP ahora está completamente configurada y puede probarla para validar que Nginx pueda proporcionar archivos .php a su procesador PHP correctamente. Esto se realiza creando un archivo PHP de prueba en la raíz de nuestro documento.

      Abra un nuevo archivo llamado info.php dentro de la raíz del documento:

      • sudo vi /opt/rh/rh-nginx112/root/usr/share/nginx/html/info.php

      Añada al archivo la línea que se muestra a continuación. En ella se incluye código PHP válido que mostrará información sobre su servidor:

      112/root/usr/share/nginx/html/info.php’>/opt/rh/rh-nginx112/root/usr/share/nginx/html/info.php

      <?php phpinfo(); ?>
      

      Cuando termine, guarde y cierre el archivo. Luego, visite esta página en su navegador web usando el nombre de dominio o la dirección IP pública de su servidor seguidos de /info.php:

      http://server_domain_or_IP/info.php
      

      Verá una página web generada por PHP con información sobre su servidor:

      Información de página de PHP

      Si ve una página con este aspecto, significa que habrá configurado el procesamiento de PHP con Nginx de forma satisfactoria.

      Tras verificar que Nginx represente la página de forma correcta, la mejor opción será eliminar el archivo que creó porque puede dar indicios sobre su configuración que podrían ser útiles para que usuarios no autorizados intenten ingresar. Siempre puede regenerar este archivo si lo necesita más adelante.

      Elimine el archivo escribiendo lo siguiente:

      • sudo rm /opt/rh/rh-nginx112/root/usr/share/nginx/html/info.php

      Con esto, confirmará que todos los componentes de la pila LEMP se instalaron y configuraron correctamente en su servidor.

      Conclusión

      Ahora contará con una pila LEMP totalmente segura en su servidor CentOS 7. Esto le proporcionará una base muy flexible para proporcionar contenido web a sus visitantes.

      Las SCLs también se utilizan para instalar varias versiones de software y alternar entre ellas. Puede ver la lista de todas las colecciones instaladas en el sistema ejecutando lo siguiente:

      Si le interesa, podrá encontrar más información sobre Software Collections en el sitio oficial.



      Source link

      Como criar um API Gateway Usando o Ambassador no Kubernetes da DigitalOcean


      O autor escolheu a Free and Open Source Fund para receber uma doação como parte do programa Write for DOnations.

      Introdução

      O Ambassador é um API Gateway para aplicações nativas em nuvem que roteia o tráfego entre serviços heterogêneos e mantém fluxos de trabalho descentralizados. Ele atua como um único ponto de entrada e suporta tarefas como descoberta de serviço, gerenciamento de configuração, regras de roteamento e limitação de taxas de acesso. Ele também oferece grande flexibilidade e facilidade de configuração para seus serviços.

      O Envoy é um proxy de serviço de código aberto projetado para aplicações nativas em nuvem. No Kubernetes, o Ambassador pode ser usado para instalar e gerenciar a configuração do Envoy. O Ambassador suporta alterações na configuração com tempo zero de inatividade e integração com outros recursos, como autenticação, descoberta de serviços e service meshes.

      Neste tutorial, você configurará um Ambassador API Gateway em um cluster Kubernetes usando o Helm e o configurará para rotear o tráfego de entrada para vários serviços com base nas regras de roteamento. Você configurará essas regras para rotear o tráfego com base no nome do host ou no caminho para os serviços relevantes.

      Pré-requisitos

      Antes de começar este guia, você precisará do seguinte:

      • Um cluster Kubernetes na DigitalOcean com o kubectl configurado. Para criar um cluster Kubernetes na DigitalOcean, veja nosso guia Kubernetes Quickstart.

      • O gerenciador de pacotes Helm instalado em sua máquina local e o Tiller instalado em seu cluster. Complete os passos 1 e 2 do tutorial How To Install Software on Kubernetes Clusters with the Helm Package Manager

      • Um nome de domíno totalmente qualificado com pelo menos dois registros A configurados. Ao longo deste tutorial iremos utilizar svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio. Você pode seguir o guia DNS Quickstart para configurar seus registros na DigitalOcean.

      Passo 1 — Instalando o Ambassador

      Nesta seção, você instalará o Ambassador no seu cluster Kubernetes. O Ambassador pode ser instalado usando um chart do Helm ou passando um arquivo de configuração YAML para o comando kubectl.

      Nota: O Kubernetes na DigitalOcean tem o RBAC ativado por padrão, portanto, ao usar um arquivo de configuração YAML para instalação, é necessário garantir que você use o RBAC ativado. Você pode encontrar mais detalhes sobre o deployment do Ambassador no Kubernetes via YAML na documentação do Ambassador

      Para os propósitos deste tutorial, você usará um chart do Helm para instalar o Ambassador no seu cluster. Após seguir os pré-requisitos, você terá o Helm instalado em seu cluster.

      Para começar, execute o seguinte comando para instalar o Ambassador via Helm:

      • helm upgrade --install --wait ambassador stable/ambassador

      Você verá uma saída semelhante à seguinte:

      Output

      Release "ambassador" does not exist. Installing it now. NAME: ambassador LAST DEPLOYED: Tue Jun 18 02:15:00 2019 NAMESPACE: default STATUS: DEPLOYED RESOURCES: ==> v1/Deployment NAME READY UP-TO-DATE AVAILABLE AGE ambassador 3/3 3 3 2m39s ==> v1/Pod(related) NAME READY STATUS RESTARTS AGE ambassador-7d55c468cb-4gpq9 1/1 Running 0 2m38s ambassador-7d55c468cb-jr9zr 1/1 Running 0 2m38s ambassador-7d55c468cb-zhm7l 1/1 Running 0 2m38s ==> v1/Service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ambassador LoadBalancer 10.245.183.114 139.59.52.164 80:30001/TCP,443:31557/TCP 2m40s ambassador-admins ClusterIP 10.245.46.43 <none> 8877/TCP 2m41s ==> v1/ServiceAccount NAME SECRETS AGE ambassador 1 2m43s ==> v1beta1/ClusterRole NAME AGE ambassador 2m41s ==> v1beta1/ClusterRoleBinding NAME AGE ambassador 2m41s ==> v1beta1/CustomResourceDefinition NAME AGE authservices.getambassador.io 2m42s consulresolvers.getambassador.io 2m41s kubernetesendpointresolvers.getambassador.io 2m42s kubernetesserviceresolvers.getambassador.io 2m43s mappings.getambassador.io 2m41s modules.getambassador.io 2m41s ratelimitservices.getambassador.io 2m42s tcpmappings.getambassador.io 2m41s tlscontexts.getambassador.io 2m42s tracingservices.getambassador.io 2m43s . . .

      Isso criará um deployment do Ambassador, um serviço e um balanceador de carga do Ambassador com os seus nodes do cluster Kubernetes conectados. Você precisará do IP do balanceador de carga para mapeá-lo para os registros A do seu domínio

      Para obter o endereço IP do balanceador de carga do seu Ambassador, execute o seguinte:

      • kubectl get svc --namespace default ambassador

      Você verá uma saída semelhante a:

      Output

      NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ambassador LoadBalancer IP-do-seu-cluster seu-endereço-IP 80:30001/TCP,443:31557/TCP 8m4s

      Observe o IP externo seu-endereço-IP neste passo e mapeie os domínios (através de seu provedor de domínio) svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio para apontar para este endereço IP.

      Você pode ativar o HTTPS com o seu balanceador de carga na DigitalOcean usando os passos fornecidos em Como configurar a terminação SSL. É recomendável configurar a terminação TLS por meio do balanceador de carga. Outra maneira de configurar a terminação TLS é usar o Suporte TLS do Ambassador

      Você instalou o Ambassador no seu cluster Kubernetes usando o Helm, que criou um deployment do Ambassador com três réplicas no namespace padrão. Isso também criou um balanceador de carga com um IP público para rotear todo o tráfego em direção ao API Gateway. Em seguida, você criará deployments do Kubernetes para três serviços diferentes que você usará para testar esse API Gateway.

      Passo 2 — Configurando Deployments de Servidor Web

      Nesta seção, você criará três deployments para executar três containers de servidor web diferentes. Você criará arquivos YAML com definições de deployments do Kubernetes para os três diferentes containers de servidores web e fará o deploy usando o kubectl.

      Abra seu editor de texto preferido para criar seu primeiro deployment para um servidor web Nginx:

      Digite a seguinte configuração yaml no seu arquivo:

      svc1-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc1
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: nginx
            name: svc1
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: nginx
              name: svc1
          spec:
            containers:
            - name: nginx
              image: nginx:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container nginx:latest a ser deployada com 1 réplica, chamada svc1. O Deployment é definido para expor o cluster na porta 80.

      Salve e feche o arquivo.

      Em seguida, execute o seguinte comando para aplicar esta configuração:

      • kubectl apply -f svc1-deploy.yaml

      Você verá a saída confirmando a criação:

      Output

      deployment.extensions/svc1 created

      Agora, crie um segundo deployment de servidor web. Abra um arquivo chamado svc2-deploy.yaml com:

      Digite a seguinte configuração YAML no arquivo:

      svc2-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc2
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: httpd
            name: svc2
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: httpd
              name: svc2
          spec:
            containers:
            - name: httpd
              image: httpd:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container httpd a ser deployada com 1 réplica, chamada svc2.

      Salve e feche o arquivo.

      Execute o seguinte comando para aplicar esta configuração:

      • kubectl apply -f svc2-deploy.yaml

      Você verá esta saída:

      Output

      deployment.extensions/svc2 created

      Finalmente, para o terceiro deployment, abra e crie o arquivo svc3-deploy.yaml:

      Adicione as seguintes linhas ao arquivo:

      svc3-deploy.yaml

      apiVersion: extensions/v1beta1
      kind: Deployment
      metadata:
        name: svc3
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: httpbin
            name: svc3
        strategy:
          type: RollingUpdate
        template:
          metadata:
            labels:
              app: httpbin
              name: svc3
          spec:
            containers:
            - name: httpbin
              image: kennethreitz/httpbin:latest
              ports:
              - name: http
                containerPort: 80
      

      Aqui você definiu um Deployment do Kubernetes com a imagem de container httpbin a ser deployada com 1 réplica, chamada svc3.

      Salve e feche o arquivo.

      Por fim, execute o seguinte comando para aplicar:

      • kubectl apply -f svc3-deploy.yaml

      E você verá a seguinte saída:

      Output

      deployment.extensions/svc3 created

      Você fez o deploy de três containers de servidor web usando deployments do Kubernetes. No próximo passo, você irá expor esses deployments ao tráfego da Internet.

      Nesta seção, você irá expor suas aplicações web à Internet, criando os Serviços Kubernetes com Anotações do Ambassador para configurar regras para rotear o tráfego para eles. Annotations ou Anotações no Kubernetes são uma maneira de adicionar metadados aos objetos. O Ambassador usa esses valores de anotação dos serviços para configurar suas regras de roteamento.

      Como lembrete, você precisa ter seus domínios (por exemplo: svc1.seu-domínio, svc2.seu-domínio e svc3.seu-domínio) mapeados para o IP público do balanceador de carga em seus registros DNS.

      Defina um serviço Kubernetes para o deployment do svc1 com anotações do Ambassador, criando e abrindo este arquivo:

      Nota: O nome do mapeamento deve ser exclusivo para cada bloco de anotação do Ambassador. O mapeamento atua como um identificador para cada bloco de anotação e, se repetido, ele irá sobrepor o bloco de anotação mais antigo.

      svc1-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc1
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc1-service_mapping
            host: svc1.seu-domínio
            prefix: /
            service: svc1:80
      spec:
        selector:
          app: nginx
          name: svc1
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Neste código YAML, você definiu um serviço Kubernetes svc1 usando anotações do Ambassador para mapear o nome do host svc1.seu-domínio para este serviço.

      Salve e saia do arquivo svc1-service.yaml e execute o seguinte para aplicar esta configuração:

      • kubectl apply -f svc1-service.yaml

      Você verá esta saída:

      Output

      service/svc1 created

      Crie seu segundo serviço Kubernetes para o deployment do svc2 com anotações do Ambassador. Este é outro exemplo de roteamento baseado em host com o Ambassador:

      Adicione a seguinte configuração ao arquivo:

      svc2-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc2
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc2-service_mapping
            host: svc2.seu-domínio
            prefix: /
            service: svc2:80
      spec:
        selector:
          app: httpd
          name: svc2
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Salve isso como svc2-service.yaml. Aqui, você definiu outro serviço Kubernetes usando anotações do Ambassador para rotear o tráfego para svc2 quando qualquer solicitação é recebida pelo Ambassador com o valor do cabeçalho host como svc2.seu-domínio. Portanto, esse roteamento baseado em host permitirá que você envie uma solicitação ao subdomínio svc2.seu-domínio, que encaminhará o tráfego para o serviço svc2 e servirá sua solicitação a partir do servidor web httpd.

      Para criar este serviço, execute o seguinte:

      • kubectl apply -f svc2-service.yaml

      Você verá a seguinte saída:

      Output

      service/svc2 created

      Crie um terceiro serviço Kubernetes para seu deployment svc3 e sirva-o através do caminho svc2.seu-domínio/bin. Isso configurará o roteamento baseado em caminho para o Ambassador:

      svc3-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc3
      spec:
        selector:
          app: httpbin
          name: svc3
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Salve isso como svc3-service.yaml e execute o seguinte para aplicar a configuração:

      • kubectl apply -f svc3-service.yaml

      Sua saída será:

      Output

      service/svc3 created

      Edite svc2-service.yaml para acrescentar o segundo bloco de anotação do Ambassador para rotear o /bin para o serviço svc3:

      svc2-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc2
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc2-service_mapping
            host: svc2.seu-domínio
            prefix: /
            service: svc2:80
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc3-service_mapping
            host: svc2.seu-domínio
            prefix: /bin
            service: svc3:80
      spec:
        selector:
          app: httpd
          name: svc2
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Você adicionou o segundo bloco de anotação do Ambassador para configurar os caminhos que começam com /bin para mapear para o seu serviço Kubernetes svc3. Para rotear solicitações de svc2.seu-domínio/bin para svc3, você adicionou o segundo bloco de anotação aqui com o valor do host svc2.seu-domínio, que é o mesmo para os dois blocos. Portanto, o roteamento baseado em caminho permitirá que você envie uma solicitação ao svc2.seu-domínio/bin, que será recebido pelo serviço svc3 e servido pela aplicação httpbin neste tutorial.

      Agora execute o seguinte para aplicar as alterações:

      • kubectl apply -f svc2-service.yaml

      Você verá esta saída:

      Output

      service/svc2 configured

      Você criou os Serviços Kubernetes para os três deployments e adicionou regras de roteamento com base no host e no caminho com as anotações do Ambassador. Em seguida, você adicionará configuração avançada a esses serviços para configurar o roteamento, o redirecionamento e cabeçalhos personalizados.

      Passo 4 — Configurações Avançadas do Ambassador para Roteamento

      Nesta seção, você irá configurar os serviços com mais anotações do Ambassador para modificar cabeçalhos e configurar redirecionamento.

      Faça um curl no domínio svc1.seu-domínio e verifique os cabeçalhos de resposta:

      • curl -I svc1.seu-domínio

      Sua saída será semelhante à seguinte:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 21:41:00 GMT content-type: text/html content-length: 612 last-modified: Tue, 21 May 2019 14:23:57 GMT etag: "5ce409fd-264" accept-ranges: bytes x-envoy-upstream-service-time: 0

      Esta saída mostra os cabeçalhos recebidos do serviço roteado usando o Ambassador. Você adicionará cabeçalhos personalizados à sua resposta de serviço usando as anotações do Ambassador e validará a saída para os novos cabeçalhos adicionados.

      Para adicionar cabeçalhos personalizados à sua resposta de serviço, remova o cabeçalho x-envoy-upstream-service-time da resposta e adicione um novo cabeçalho de resposta x-geo-location: Brazil para o svc1. (Você pode alterar este cabeçalho conforme seus requisitos.)

      Edite o arquivo svc1-service.yaml:

      Atualize a anotação com as seguintes linhas destacadas:

      svc1-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc1
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Mapping
            name: svc1-service_mapping
            host: svc1.example.com
            prefix: /
            remove_response_headers:
            - x-envoy-upstream-service-time
            add_response_headers:
              x-geo-location: Brazil
            service: svc1:80
      spec:
        selector:
          app: nginx
          name: svc1
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Aqui você modificou o serviço svc1 para remover x-envoy-upstream-service-time e adicionou o cabeçalho x-geo-location: Brazil na resposta HTTP.

      Aplique as alterações que você fez:

      • kubectl apply -f svc1-service.yaml

      Você verá a seguinte saída:

      Output

      service/svc1 configured

      Agora execute curl para validar os cabeçalhos atualizados na resposta do serviço:

      • curl -I svc1.seu-domínio

      A saída será semelhante a esta:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 21:45:26 GMT content-type: text/html content-length: 612 last-modified: Tue, 21 May 2019 14:23:57 GMT etag: "5ce409fd-264" accept-ranges: bytes x-geo-location: Brazil

      Agora edite o svc3-service.yaml para redirecionar solicitações para o seu nome de host svc3.seu-domínio para o caminho svc2.seu-domínio/bin:

      Acrescente o bloco de anotação do Ambassador, conforme mostrado no YAML a seguir, e salve-o:

      svc3-service.yaml

      apiVersion: v1
      kind: Service
      metadata:
        name: svc3
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind:  Mapping
            name:  redirect_mapping
            host: svc3.seu-domínio
            prefix: /
            service: svc2.seu-domínio
            host_redirect: true
            path_redirect: /bin
      spec:
        selector:
          app: httpbin
          name: svc3
        ports:
        - name: http
          protocol: TCP
          port: 80
      

      Você adicionou host_redirect: true para configurar uma resposta de redirecionamento 301 de svc3 para svc2.seu-domínio/bin para o nome de host svc3.seu-domínio . O parâmetro host_redirect envia uma resposta de redirecionamento 301 para o cliente. Se não estiver definido, as requisições receberão respostas 200 HTTP em vez de respostas 301 HTTP.

      Agora execute o seguinte comando para aplicar essas alterações:

      • kubectl apply -f svc3-service.yaml

      Você verá uma saída semelhante a:

      Output

      service/svc3 configured

      Agora você pode verificar a resposta para svc3.seu-domínio usando curl:

      • curl -I svc3.seu-domínio

      Sua saída será semelhante à seguinte:

      Output

      HTTP/1.1 301 Moved Permanently location: http://svc2.seu-domínio/bin date: Mon, 17 Jun 2019 21:52:05 GMT server: envoy transfer-encoding: chunked

      A saída é um cabeçalho HTTP para a resposta da solicitação ao serviço svc3.seu-domínio mostrando que a configuração de host_redirect: true na anotação do serviço forneceu corretamente o código de status HTTP: 301 Moved Permanently.

      Você configurou o serviço com anotações do Ambassador para modificar cabeçalhos HTTP e configurar redirecionamentos. Em seguida, você adicionará a configuração global ao serviço Ambassador API Gateway.

      Passo 5 — Definindo Configurações Globais do Ambassador

      Nesta seção, você editará o serviço Ambassador para adicionar a configuração global de compactação GZIP. A compactação GZIP compactará o tamanho dos assets HTTP e reduzirá os requisitos de largura de banda da rede, levando a tempos de resposta mais rápidos para os clientes web. Essa configuração afeta todo o tráfego que está sendo roteado pelo Ambassador API Gateway. Da mesma forma, você pode configurar outros módulos globais com o Ambassador, que permitem ativar comportamentos especiais para o serviço em nível global. Essas configurações globais podem ser aplicadas usando anotações do serviço Ambassador. Você pode consultar a documentação da Configuração Global do Ambassador para obter mais informações.

      O seguinte comando kubectl edit abrirá o editor padrão, que é o vim. Para usar o nano, por exemplo, você pode definir a variável de ambiente KUBE_EDITOR como nano:

      • export KUBE_EDITOR="nano"

      Edite o serviço Ambassador:

      • kubectl edit service ambassador

      Agora adicione as linhas destacadas a um novo bloco de anotação para compactação GZIP:

      Editing Ambassador Service

      apiVersion: v1
      kind: Service
      metadata:
        annotations:
          getambassador.io/config: |
            ---
            apiVersion: ambassador/v1
            kind: Module
            name: ambassador
            config:
              service_port: 8080
            ---
            apiVersion: ambassador/v0
            kind:  Module
            name:  ambassador
            config:
              gzip:
                memory_level: 5
                min_content_length: 256
                compression_level: BEST
                compression_strategy: DEFAULT
                content_type:
                - application/javascript
                - application/json
                - text/html
                - text/plain
                disable_on_etag_header: false
                remove_accept_encoding_header: false
        creationTimestamp: "2019-06-17T20:45:04Z"
        labels:
          app.kubernetes.io/instance: ambassador
          app.kubernetes.io/managed-by: Tiller
          app.kubernetes.io/name: ambassador
          helm.sh/chart: ambassador-2.8.2
        name: ambassador
        namespace: default
        resourceVersion: "2153"
        . . .
      

      Você adicionou o bloco de anotação do Ambassador ao seu serviço Ambassador e configurou o GZIP globalmente para o API Gateway. Aqui você incluiu a configuração para controlar a quantidade de memória interna usada com memory_level, que pode ser um valor de 1 a 9. O compression_level configurado como BEST garante uma taxa de compactação mais alta, com o custo de uma latência mais alta. Com o min_content_length, você configurou o comprimento mínimo de resposta para 256 bytes. Para o content_type, você incluiu especificamente um conjunto de tipos de mídia (anteriormente MIME-types) que produz compactação. Finalmente, você adicionou as duas configurações finais como false para permitir a compactação.

      Você pode ler mais sobre a compactação GZIP na página sobre GZIP do Envoy.

      Quaisquer alterações neste serviço se aplicam como configurações globais para o API Gateway.

      Depois de sair do editor, você verá uma saída semelhante à seguinte:

      Output

      service/ambassador edited

      Verifique o svc1.seu-domínio usando o curl para ver o cabeçalho content-encoding tendo o valor gzip:

      • curl --compressed -i http://svc1.example.com

      A saída será semelhante a esta:

      Output

      HTTP/1.1 200 OK server: envoy date: Mon, 17 Jun 2019 22:25:35 GMT content-type: text/html last-modified: Tue, 21 May 2019 14:23:57 GMT accept-ranges: bytes x-geo-location: Brazil vary: Accept-Encoding content-encoding: gzip transfer-encoding: chunked <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> <p>If you see this page, the nginx web server is successfully installed and working. Further configuration is required.</p> <p>For online documentation and support please refer to <a href="http://nginx.org/">nginx.org</a>.<br/> Commercial support is available at <a href="http://nginx.com/">nginx.com</a>.</p> <p><em>Thank you for using nginx.</em></p> </body> </html>

      Aqui você pode ver a página HTML padrão do Nginx com seu cabeçalho de resposta, mostrando que o content-encoding da resposta recebida é compactação gzip.

      Você adicionou a configuração global ao Ambassador para habilitar a configuração GZIP para respostas de tipos de conteúdo selecionados no API Gateway.

      Conclusão

      Você configurou com êxito um API Gateway para seu cluster Kubernetes usando o Ambassador. Agora você pode expor suas aplicações usando roteamento baseado em host e caminho, com cabeçalhos personalizados e a compactação GZIP global.

      Para obter mais informações sobre as anotações do Ambassador e parâmetros de configuração, leia a documentação oficial do Ambassador.



      Source link

      Como Transferir Spaces da DigitalOcean Entre Regiões Usando o Rclone


      Introdução

      O DigitalOcean Spaces é um serviço de armazenamento de objetos projetado para facilitar e reduzir o custo de armazenar e servir grandes quantidades de dados.

      Neste guia, abordaremos como migrar dados entre regiões do Spaces, usando o Rclone para transferir dados entre dois Spaces. Demonstraremos como instalar o Rclone, as definições de configuração necessárias para acessar várias regiões e os comandos que você pode usar para sincronizar seus arquivos entre regiões e verificar sua integridade.

      Criando Chaves de API e Localizando Informações de Endpoint do Spaces

      Antes de começarmos a instalar e configurar o Rclone para copiar nossos objetos entre os Spaces, precisaremos de algumas informações sobre nossa conta no DigitalOcean Spaces. Vamos precisar de uma chave da API do Spaces e precisamos conhecer as regiões e os nomes dos nossos Spaces de origem e destino.

      Gerando uma Chave de API do DigitalOcean Spaces

      Para criar uma chave de API do DigitalOcean Spaces, siga a seção “Creating an Access Key” de nossa documentação em How To Create a DigitalOcean Space API Key.

      Salve o ID da chave de acesso e a chave secreta. Nós os usaremos posteriormente para configurar o Rclone para acessar nossa conta.

      Localizando o Endpoint Compatível com S3 do Spaces

      Em seguida, precisamos encontrar o endpoint para cada Space. Você pode visualizar o endpoint do Space no Painel de controle da DigitalOcean, selecionando o Space e visualizando a guia Settings:

      DigitalOcean Spaces endpoint

      O endpoint sempre estará na região em que você criou o Space, seguido por .digitaloceanspaces.com. Anote o endpoint para ambos os seus Spaces. Usaremos essas informações ao criar nossa configuração rclone.

      Instalando o Rclone

      Agora você está pronto para instalar o Rclone. Você pode fazer isso na sua máquina local ou – se a largura de banda estiver limitada – você poderá instalar o Rclone em um Droplet localizado na região do Spaces de origem ou de destino.

      Visite a seção de Downloads do site do projeto para encontrar binários do utilitário compilado para diferentes plataformas. Para começar, baixe o binário compactado que corresponde ao sistema operacional do seu computador.

      Depois de baixar o arquivo zip do Rclone para o seu computador, siga a seção abaixo que corresponda à sua plataforma.

      Linux

      Antes de podermos extrair o arquivo, precisamos garantir que o utilitário unzip esteja disponível.

      Se você estiver executando o Ubuntu ou o Debian, você pode atualizar o índice local de pacotes e instalar o unzip digitando:

      • sudo apt update
      • sudo apt install unzip

      Se você estiver usando CentOS ou Fedora, você pode instalar o unzip digitando:

      Com o unzip instalado, navegue até o diretório onde você baixou o arquivo zip do rclone:

      Em seguida, descompacte o arquivo e vá para o diretório recém-criado:

      • unzip rclone*
      • cd rclone-v*

      A partir daqui, podemos copiar o binário no diretório /usr/local/bin para que ele esteja disponível em todo o sistema:

      • sudo cp rclone /usr/local/bin

      Em seguida, adicionamos a página de manual ao nosso sistema, para que possamos obter facilmente ajuda na sintaxe de comando e nas opções disponíveis. Verifique se o diretório local de manual está disponível e copie o arquivo rclone.1:

      • sudo mkdir -p /usr/local/share/man/man1
      • sudo cp rclone.1 /usr/local/share/man/man1

      Atualize o banco de dados man para adicionar a nova página de manual ao sistema:

      Por fim, podemos criar o diretório .config do Rclone e abrir um arquivo de configuração:

      • mkdir -p ~/.config/rclone
      • nano ~/.config/rclone/rclone.conf

      Isso abrirá seu editor de texto com um novo arquivo em branco. Avance para a seção Configurando o Rclone para prosseguir.

      macOS

      Se você estiver executando o macOS, comece navegando no terminal até o diretório em que você baixou o arquivo zip rclone:

      Em seguida, descompacte o arquivo e vá para o diretório recém-criado:

      • unzip -a rclone*
      • cd rclone-v*

      Depois, certifique-se de que o diretório /usr/local/bin está disponível e então copie o binário rclone para ele:

      • sudo mkdir -p /usr/local/bin
      • sudo cp rclone /usr/local/bin

      Por fim, podemos criar o diretório .config e abrir um arquivo de configuração:

      • mkdir -p ~/.config/rclone
      • nano ~/.config/rclone/rclone.conf

      Isso abrirá seu editor de texto com um novo arquivo em branco. Avance para a seção Configurando o Rclone para prosseguir.

      Windows

      Se você estiver executando o Windows, comece navegando até o diretório Downloads no Gerenciador de Arquivos do Windows. Selecione o arquivo zip rclone e clique com o botão direito do mouse. No menu de contexto que aparece, clique em Extrair tudo…:

      Windows extract rclone zip file

      Siga as instruções para extrair os arquivos do arquivo zip.

      O utilitário rclone.exe deve ser executado a partir da linha de comando. Abra uma nova janela Prompt de Comando (o programa cmd.exe) clicando no botão Windows no canto inferior esquerdo, digitando cmd e selecionando Prompt de Comando.

      Dentro do prompt, navegue até o caminho do rclone que você extraiu digitando:

      • cd "%HOMEPATH%Downloadsrclone*rclone*"

      Liste o conteúdo do diretório para verificar se você está no local correto:

      Output

      10/23/2017 01:02 PM <DIR> . 10/23/2017 01:02 PM <DIR> .. 10/23/2017 01:02 PM 17 git-log.txt 10/23/2017 01:02 PM 296,086 rclone.1 10/23/2017 01:02 PM 16,840,192 rclone.exe 10/23/2017 01:02 PM 315,539 README.html 10/23/2017 01:02 PM 261,497 README.txt 5 File(s) 17,713,331 bytes 2 Dir(s) 183,296,266,240 bytes free

      Você precisará estar neste diretório sempre que quiser usar o comando rclone.exe.

      Nota: No macOS e no Linux, executamos a ferramenta digitando rclone, mas no Windows, o comando é chamado rclone.exe. No restante deste guia, forneceremos comandos como rclone, portanto, certifique-se de substituir o rclone.exe sempre que executar no Windows.

      Em seguida, podemos criar o diretório .config e abrir um arquivo de configuração para definir nossas credenciais do S3 e do Spaces:

      • mkdir "%HOMEPATH%.configrclone"
      • notepad "%HOMEPATH%.configrclonerclone.conf"

      Isso abrirá seu editor de texto com um novo arquivo em branco. Continue em frente para aprender como definir suas regiões do Spaces no arquivo de configuração.

      Configurando o Rclone

      Vamos configurar nossas duas regiões do DigitalOcean Spaces como Rclone “remotas” no arquivo de configuração do Rclone. Cole a seção a seguir no arquivo de configuração para definir a primeira região:

      ~/.config/rclone/rclone.conf

      [spaces-sfo2]
      type = s3
      env_auth = false
      access_key_id = access_key_do_seu_spaces
      secret_access_key = secret_key_do_seu_spaces
      endpoint = sfo2.digitaloceanspaces.com
      acl = private
      

      Aqui, definimos um novo rclone “remoto” chamado spaces-sfo2. Altere o nome da região para corresponder à região do Spaces que você está configurando.

      Definimos o type como s3 para que o rclone saiba a maneira apropriada de interagir e gerenciar o recurso de armazenamento remoto. Definiremos as credenciais de acesso do Spaces neste arquivo de configuração, de forma que possamos definir env_auth como false.

      A seguir, definimos as variáveis access_key_id e secret_access_key como access key e secret key do nosso Spaces, respectivamente. Certifique-se de alterar os valores para as credenciais associadas à sua conta.

      Definimos o endpoint como o endpoint do Spaces que vimos anteriormente.

      Finalmente, definimos o acl como private para proteger nossos ativos até que desejemos compartilhá-los.

      Em seguida, faça uma duplicata do bloco de configuração que você acabou de criar, então atualize o nome e a região do endpoint para refletir sua segunda região:

      ~/.config/rclone/rclone.conf

      . . .
      
      [spaces-nyc3]
      type = s3
      env_auth = false
      access_key_id = access_key_do_seu_spaces
      secret_access_key = secret_key_do_seu_spaces
      endpoint = nyc3.digitaloceanspaces.com
      acl = private
      

      O restante da configuração deve permanecer o mesmo que para a primeira região. Salve e feche o arquivo quando terminar.

      No macOS e no Linux, certifique-se de bloquear as permissões do arquivo de configuração, pois nossas credenciais estão dentro dele:

      • chmod 600 ~/.config/rclone/rclone.conf

      No Windows, as permissões são negadas a usuários não administrativos, a menos que sejam concedidas explicitamente, portanto, não precisamos ajustar o acesso manualmente.

      Em seguida, usaremos o rclone para explorar nossos Spaces e sincronizar dados entre eles.

      Copiando Objetos do S3 para o Spaces

      Agora que nossa configuração está completa, estamos prontos para transferir nossos arquivos.

      Comece verificando os remotos configurados no rclone:

      Output

      spaces-nyc3: spaces-sfo2:

      As duas regiões que definimos são exibidas.

      Podemos ver os Spaces disponíveis, pedindo ao rclone para listar os “diretórios” associados aos remotos (certifique-se de adicionar dois pontos ao final do nome do remoto):

      Output

      -1 2019-09-23 13:07:54 -1 source-space

      A saída acima indica que um Space, chamado source-space foi encontrado na região sfo2.

      Você pode repetir o procedimento para visualizar a outra região:

      Output

      -1 2019-09-23 13:08:28 -1 destination-space

      Para visualizar o conteúdo de um Space, você pode usar o comando tree. Passe o nome remoto, seguido por dois pontos e o nome do “diretório” que você deseja listar (o nome do Space):

      • rclone tree spaces-sfo2:source-space

      Output

      / ├── Photos │ ├── 2019.01.24-23.10.27.png │ ├── 2019.01.24-23.11.39.png │ ├── 2019.01.24-23.18.00.png │ ├── 2019.01.24-23.18.18.png │ ├── 2019.01.24-23.18.30.png │ ├── 2019.01.24-23.19.32.png │ ├── 2019.01.24-23.23.06.png │ ├── 2019.01.24-23.23.53.png │ ├── 2019.01.24-23.25.14.png │ ├── 2019.01.24-23.26.22.png │ ├── 2019.01.25-12.43.35.png │ ├── 2019.03.13-14.35.34.png │ └── 2019.03.13-14.40.52.png └── Photos.zip 1 directories, 14 files

      Quando estiver pronto, você poderá copiar os arquivos entre os Spaces, digitando:

      • rclone sync spaces-sfo2:source-space spaces-nyc3:destination-space

      Assumindo que tudo correu bem, o rclone começará a copiar objetos entre os dois Spaces.

      Nota: Se você não criou anteriormente o Space de destino na região especificada, o rclone tentará criar um para você com o nome dado. Isso vai falhar se o nome fornecido já estiver sendo usado por outra conta ou se o nome não atender aos requisitos de nomenclatura para o DigitalOcean Spaces (somente letras minúsculas, números e traços).

      Quando a transferência estiver concluída, você pode verificar se os objetos foram transferidos visualizando-os com o subcomando tree:

      • rclone tree spaces-nyc3:destination-space

      Output

      / ├── Photos │ ├── 2019.01.24-23.10.27.png │ ├── 2019.01.24-23.11.39.png │ ├── 2019.01.24-23.18.00.png │ ├── 2019.01.24-23.18.18.png │ ├── 2019.01.24-23.18.30.png │ ├── 2019.01.24-23.19.32.png │ ├── 2019.01.24-23.23.06.png │ ├── 2019.01.24-23.23.53.png │ ├── 2019.01.24-23.25.14.png │ ├── 2019.01.24-23.26.22.png │ ├── 2019.01.25-12.43.35.png │ ├── 2019.03.13-14.35.34.png │ └── 2019.03.13-14.40.52.png └── Photos.zip 1 directories, 14 files

      Para uma verificação mais robusta, use o subcomando check para comparar os objetos nas duas regiões:

      • rclone check spaces-sfo2:source-space spaces-nyc3:destination-space

      Output

      2019/09/23 14:29:11 NOTICE: S3 bucket destination-space: 0 differences found 2019/09/23 14:29:11 NOTICE: S3 bucket destination-space: 14 matching files

      Isso irá comparar os valores de hash de cada objeto nos dois remotos. Você pode receber uma mensagem indicando que alguns hashes não podem ser comparados. Nesse caso, você pode executar novamente o comando com a flag --size-only (que compara com base apenas no tamanho do arquivo) ou a flag --download (que baixa cada objeto de ambos os remotos para comparar localmente) para verificar a integridade da transferência.

      Conclusão

      Neste guia, abordamos como transferir objetos entre duas regiões do DigitalOcean Spaces. Reunimos credenciais de API e informações de endpoint do serviço Spaces, instalamos e configuramos o utilitário rclone em nosso computador local e, em seguida, copiamos todos os objetos de um Space de origem para um Space de destino.

      O cliente rclone pode ser usado para muitas outras tarefas de gerenciamento de armazenamento de objetos, incluindo upload ou download de arquivos, montagem de Spaces no sistema de arquivos local e criação ou exclusão de Spaces adicionais. Confira a página de man para aprender mais sobre as funcionalidades que a ferramenta fornece.



      Source link