Migración de aplicaciones

Completado

Una vez que migre la base de datos del entorno local a Azure, debe actualizar las aplicaciones existentes para que puedan acceder a PostgreSQL en su ubicación nueva.

La base de datos y el servidor locales originales contendrán roles que definan los privilegios asociados a los usuarios, las operaciones que pueden realizar y los objetos en los que realizan estas operaciones. Azure Database for PostgreSQL usa los mismos mecanismos de autenticación y autorización que la instancia de PostgreSQL que se ejecuta en el entorno local.

En esta unidad, explorará las actualizaciones que necesita llevar a cabo en las aplicaciones a fin de conectarse a la instancia de Azure Database for PostgreSQL que acaba de migrar.

Creación manual de los roles de usuario

Al transferir una base de datos PostgreSQL a Azure Database for PostgreSQL mediante Azure Database Migration Service, los roles y las asignaciones de roles no se copian. En la base de datos de destino, debe volver a crear manualmente las cuentas de usuario y los roles necesarios para el administrador y los usuarios de las tablas. Puede usar las utilidades psql o pgAdmin para realizar estas tareas. Ejecute el comando CREATE ROLE. Puede usar el comando GRANT para asignar los privilegios necesarios a un rol. Por ejemplo:

CREATE ROLE myuseraccount WITH LOGIN NOSUPERUSER CREATEDB PASSWORD 'mY!P@ss0rd';
GRANT ALL PRIVILEGES ON DATABASE mydatabase TO myuseraccount;

Nota

Use también el comando createuser desde el símbolo del sistema de Bash para crear roles de PostgreSQL.

Para ver los roles existentes en la base de datos local, ejecute la instrucción SQL siguiente:

SELECT rolname
FROM pg_roles;

Puede usar el comando \du de la utilidad psql para mostrar los privilegios asignados a los roles.

                              List of roles
   Role name   |               Attributes                                   | Member of
---------------+------------------------------------------------------------+-----------
 azureuser     | Superuser, Create DB                                       | {}
 myuseraccount | Create DB                                                  | {}
 postgres      | Superuser, Create role, Create DB, Replication, Bypass RLS | {}

Nota:

Tenga en cuenta que Azure Database for PostgreSQL agrega algunos roles propios. Estos roles incluyen azure_pg_admin, azure_superuser y el usuario administrador que especificó cuando creó el servicio. Inicie sesión con sus cuentas administrativas, pero los otros dos roles están reservados para que Azure los utilice, así que no debe intentar usarlos por su cuenta.

Reconfiguración de las aplicaciones

Volver a configurar una aplicación para que se conecte a Azure Database for PostgreSQL es un proceso sencillo. Sin embargo, es más importante determinar una estrategia para las aplicaciones de migración.

Consideraciones al volver a configurar aplicaciones PostgreSQL

En un entorno corporativo, es posible que tenga muchas aplicaciones que se ejecutan en las mismas bases de datos PostgreSQL. Podría haber un gran número de usuarios que ejecutan estas aplicaciones. Debe asegurarse de que, al cambiar del sistema existente a Azure Database for PostgreSQL, los sistemas seguirán funcionando, los usuarios podrán seguir haciendo sus trabajos y las operaciones críticas para la empresa seguirán siendo operativas. En el módulo 1, lección 2, Consideraciones sobre la migración, se analizaron muchos de los problemas en términos generales. Al migrar una base de datos PostgreSQL a Azure, hay algunos detalles que deben tenerse en cuenta:

  • Si realiza una migración sin conexión, los datos de la base de datos PostgreSQL original y las bases de datos nuevas que se ejecutan en Azure pueden empezar a divergir rápidamente si todavía se usa la base de datos anterior. Una migración sin conexión es adecuada cuando un sistema deja de funcionar por completo durante un tiempo y, a continuación, se cambian todas las aplicaciones al sistema nuevo antes de iniciarlo de nuevo. Es posible que este enfoque no sea adecuado en un sistema crítico para la empresa. Si va a migrar a PostgreSQL que se ejecuta en una máquina virtual de Azure, configure la replicación de PostgreSQL entre el sistema local y el que se ejecuta en Azure. La replicación nativa de PostgreSQL solo funciona en una dirección, pero hay soluciones de terceros que admiten la replicación bidireccional entre servidores PostgreSQL (estas soluciones no funcionan con Azure Database for PostgreSQL).
  • Si realiza una migración en línea, el servicio Azure Database for PostgreSQL configura la replicación de la base de datos local a la base de datos que se ejecuta en Azure. Después de la transferencia de datos inicial, la replicación garantiza que los cambios hechos en la base de datos local se copien en la base de datos en Azure y no al revés.

En ambos casos, debe asegurarse de no perder los datos activos a causa de una sobrescritura accidental. Por ejemplo, en el escenario en línea, una aplicación que sigue usando la base de datos local podría sobrescribir de manera inadvertida los cambios de una aplicación conectada a la base de datos que se ejecuta en Azure Database for PostgreSQL. Teniendo esto en cuenta, considere los enfoques siguientes:

  • Migre las aplicaciones en función de su tipo de carga de trabajo. Una aplicación con acceso de solo lectura a los datos ahora puede pasar de manera segura a la base de datos que se ejecuta en Azure Database for PostgreSQL y verá todos los cambios hechos por las aplicaciones que siguen usando la base de datos local. También puede adoptar la estrategia inversa si las aplicaciones de solo lectura no requieren datos totalmente actualizados.
  • Migre los usuarios en función de su tipo de carga de trabajo. Esta estrategia es similar a la anterior, con la salvedad de que podría tener usuarios que solo generan informes mientras que otros modifican los datos. Puede configurar la misma aplicación para que se conecte a la base de datos adecuada según los requisitos del usuario.
  • Migre las aplicaciones en función de los conjuntos de datos que usan. Si varias aplicaciones usan subconjuntos distintos de los datos, es posible que pueda migrar estas aplicaciones de forma independiente.

Reconfiguración de una aplicación

Para volver a configurar una aplicación, debe apuntarla a la base de datos nueva. La mayoría de las aplicaciones bien escritas aislarán la lógica de conexión, y esta debe ser la única parte del código que requiere un cambio. En muchos casos, la información de conexión puede almacenarse como información de configuración; solo necesita actualizar esa información.

Encontrará la información de conexión para el servicio Azure Database for PostgreSQL en Azure Portal, en la página Cadenas de conexión del servicio. Azure proporciona la información de muchos marcos y lenguajes de programación comunes.

Image showing the Connection strings page for Azure Database for PostgreSQL item in the Azure portal

Apertura de puertos de red

Como se mencionó en la lección 1 de este módulo, Azure Database for PostgreSQL es un servicio protegido que se ejecuta detrás de un firewall. Los clientes no se pueden conectar a menos que el servicio reconozca su dirección IP. Debe agregar las direcciones IP o los intervalos de bloques de direcciones para los clientes que ejecutan aplicaciones que necesitan conectarse a las bases de datos.

Prueba y comprobación de aplicaciones

Antes de cambiar las aplicaciones y los usuarios a la base de datos nueva, es importante asegurarse de que configuró todo correctamente.

Empiece por las aplicaciones de "ejecución en seco" y conecte cada rol para garantizar que está disponible la funcionalidad correcta.

A continuación, realice "pruebas de inmersión" para imitar el número típico de usuarios que ejecutan cargas de trabajo de manera simultánea durante un período de tiempo. Supervise el sistema y compruebe que asignó recursos suficientes a su servicio Azure Database for PostgreSQL.

En este punto, puede empezar a lanzar el sistema para los usuarios. Puede ser útil implementar alguna forma de "pruebas controladas", en las que un subconjunto pequeño de los usuarios se transfiere sin saberlo al sistema. Esto le ofrece una opinión no sesgada respecto de si los usuarios tienen una experiencia mejor, peor o similar con la base de datos nueva.