En Kinsta, tenemos proyectos de todos los tama\u00f1os para el alojamiento de aplicaciones, el alojamiento de bases de datos y el alojamiento administrado de WordPress.<\/p>\n
Con las soluciones de alojamiento en la nube de Kinsta, puedes desplegar aplicaciones<\/a> en varios lenguajes y frameworks, como NodeJS, PHP, Ruby, Go, Scala y Python. Con un Dockerfile, puedes desplegar cualquier aplicaci\u00f3n. Puedes conectar tu repositorio Git (alojado en GitHub, GitLab o Bitbucket) para desplegar tu c\u00f3digo directamente en Kinsta.<\/p>\n Puedes alojar bases de datos MariaDB, Redis, MySQL y PostgreSQL<\/a> listas para usar, ahorr\u00e1ndote tiempo para centrarte en desarrollar tus aplicaciones en lugar de sufrir con las configuraciones de alojamiento.<\/p>\n Y si eliges nuestro Alojamiento WordPress Administrado<\/a>, experimentar\u00e1s la potencia de las m\u00e1quinas Google Cloud C2 en su red de nivel Premium y la seguridad integrada de Cloudflare, haciendo que tus sitios web WordPress sean los m\u00e1s r\u00e1pidos y seguros del mercado.<\/p>\n Uno de los mayores retos de desarrollar y mantener aplicaciones nativas de la nube a nivel empresarial es tener una experiencia coherente a lo largo de todo el ciclo de vida de desarrollo. Esto es a\u00fan m\u00e1s dif\u00edcil para empresas remotas con equipos distribuidos que trabajan en plataformas diferentes, con configuraciones distintas y comunicaci\u00f3n as\u00edncrona. Necesitamos proporcionar una soluci\u00f3n coherente, fiable y escalable que funcione para:<\/p>\n En Kinsta, confiamos mucho en Docker<\/a> para esta experiencia consistente en cada paso, desde el desarrollo hasta la producci\u00f3n. En este post, te guiaremos a trav\u00e9s de:<\/p>\n Ejecutar una aplicaci\u00f3n localmente requiere que los desarrolladores preparen meticulosamente el entorno, instalen todas las dependencias, configuren servidores y servicios, y se aseguren de que est\u00e1n bien configurados. Cuando ejecutas varias aplicaciones, esto puede resultar engorroso, especialmente cuando se trata de proyectos complejos con m\u00faltiples dependencias. Cuando introduces en esta variable m\u00faltiples colaboradores con m\u00faltiples sistemas operativos, se instala el caos. Para evitarlo, utilizamos Docker.<\/p>\n Con Docker, puedes declarar las configuraciones del entorno, instalar las dependencias y construir im\u00e1genes con todo donde debe estar. Cualquiera, en cualquier lugar, con cualquier SO puede utilizar las mismas im\u00e1genes y tener exactamente la misma experiencia que los dem\u00e1s.<\/p>\n Para empezar, crea un archivo Docker Compose<\/a>, Los archivos Docker Compose resultan muy \u00fatiles cuando tienes m\u00e1s de un contenedor en ejecuci\u00f3n y existen dependencias entre contenedores. Para crear tu archivo Junt\u00e1ndolo todo, tenemos un En primer lugar, tenemos que crear una imagen Docker utilizando Consejo profesional: Ten en cuenta que La mayor\u00eda de nuestras aplicaciones y servicios utilizan CI\/CD para su despliegue. Docker desempe\u00f1a un papel importante en el proceso. Cada cambio en la rama principal desencadena inmediatamente una cadena de construcci\u00f3n a trav\u00e9s de Acciones de GitHub o CircleCI. El flujo de trabajo general es muy sencillo: instala las dependencias, ejecuta las pruebas, construye la imagen Docker y la env\u00eda a Google Container Registry (o Artifact Registry). La parte que trataremos en este art\u00edculo es el paso de construcci\u00f3n.<\/p>\n Utilizamos construcciones en varias etapas por razones de seguridad y rendimiento.<\/p>\n En esta etapa copiamos todo el c\u00f3digo base con todo el c\u00f3digo fuente y la configuraci\u00f3n, instalamos todas las dependencias, incluidas las dependencias dev, y construimos la aplicaci\u00f3n. Crea una carpeta La mayor\u00eda de la gente utiliza esta etapa para el tiempo de ejecuci\u00f3n, ya que est\u00e1 muy cerca de lo que necesitamos para ejecutar la aplicaci\u00f3n. Sin embargo, todav\u00eda tenemos que instalar las dependencias de producci\u00f3n y eso significa que dejamos huellas y necesitamos la carpeta La \u00faltima etapa tiene que ser lo m\u00e1s delgada posible, con huellas m\u00ednimas. As\u00ed que simplemente copiamos la aplicaci\u00f3n totalmente horneada de producci\u00f3n y seguimos adelante. Dejamos atr\u00e1s todas esas cosas de Yarn y Este es el Observa que, para todas las etapas, empezamos copiando primero los archivos Supongamos que has cambiado algo en Existen varias formas de construir una imagen Docker en las canalizaciones CircleCI. En nuestro caso, elegimos utilizar Gracias a Docker, se necesita una configuraci\u00f3n m\u00ednima para crear y enviar nuestra aplicaci\u00f3n.<\/p>\n Como alternativa a CircleCI, podemos utilizar GitHub Actions para desplegar la aplicaci\u00f3n de forma continua. Configuramos Con cada peque\u00f1o cambio empujado a la rama principal, construimos y enviamos una nueva imagen Docker al registro.<\/p>\n Disponer de im\u00e1genes Docker listas para usar para todos y cada uno de los cambios tambi\u00e9n facilita el despliegue en producci\u00f3n o el retroceso en caso de que algo vaya mal. Utilizamos Google Kubernetes Engine para gestionar y servir nuestras aplicaciones, y utilizamos Google Cloud Deploy y Delivery Pipelines para nuestro proceso de despliegue continuo.<\/p>\n Cuando la imagen Docker se construye despu\u00e9s de cada peque\u00f1o cambio (con la tuber\u00eda CI mostrada arriba) damos un paso m\u00e1s y desplegamos el cambio en nuestro cl\u00faster de desarrollo utilizando Esto desencadena un proceso de lanzamiento para desplegar los cambios en nuestro cl\u00faster Kubernetes dev. Despu\u00e9s de probar y obtener las aprobaciones, promovemos el cambio a staging y luego a producci\u00f3n. Todo esto es posible porque tenemos una imagen Docker aislada para cada cambio que tiene casi todo lo que necesita. S\u00f3lo tenemos que indicar al despliegue qu\u00e9 etiqueta debe utilizar.<\/p>\n El equipo de control de calidad necesita sobre todo una versi\u00f3n en la nube previa a la producci\u00f3n de las aplicaciones que va a probar. Sin embargo, a veces necesitan ejecutar localmente una aplicaci\u00f3n preconstruida (con todas las dependencias) para probar una determinada funci\u00f3n. En estos casos, no quieren o no necesitan pasar por todo el dolor de clonar todo el proyecto, instalar paquetes npm, construir la app, enfrentarse a errores de desarrollador y repasar todo el proceso de desarrollo para poner la app en marcha. Ahora que todo est\u00e1 ya disponible como imagen Docker en Google Container Registry, todo lo que necesitan es un servicio en el archivo Docker compose:<\/p>\n Con este servicio, pueden poner en marcha la aplicaci\u00f3n en sus m\u00e1quinas locales utilizando contenedores Docker ejecutando:<\/p>\n Este es un gran paso hacia la simplificaci\u00f3n de los procesos de prueba. Incluso si el control de calidad decide probar una etiqueta espec\u00edfica de la aplicaci\u00f3n, puede cambiar f\u00e1cilmente la etiqueta de la imagen en la l\u00ednea 6 y volver a ejecutar el comando Docker compose. Incluso si deciden comparar diferentes versiones de la aplicaci\u00f3n simult\u00e1neamente, pueden conseguirlo f\u00e1cilmente con unos pocos ajustes. La mayor ventaja es mantener a nuestro equipo de control de calidad alejado de los retos de los desarrolladores.<\/p>\nSuperar el Reto de Desarrollar Aplicaciones Nativas de la Nube en un Equipo Distribuido<\/h2>\n
\n
\n
Utilizaci\u00f3n de Docker Desktop para Mejorar la Experiencia de los Desarrolladores<\/h2>\n
Declara Tu Configuraci\u00f3n con Docker Compose<\/h2>\n
docker-compose.yml<\/code>. Es un archivo de configuraci\u00f3n declarativo escrito en formato YAML que indica a Docker cu\u00e1l es el estado deseado de tu aplicaci\u00f3n. Docker utiliza esta informaci\u00f3n para configurar el entorno de tu aplicaci\u00f3n.<\/p>\ndocker-compose.yml<\/code>:<\/p>\n\n
image<\/code><\/a> como base para nuestra aplicaci\u00f3n. Busca en Docker Hub e intenta encontrar una imagen Docker que ya contenga las dependencias de tu aplicaci\u00f3n. Aseg\u00farate de utilizar una etiqueta de imagen espec\u00edfica para evitar errores. Utilizar la etiqueta latest<\/code> puede causar errores imprevistos en tu aplicaci\u00f3n. Puedes utilizar varias im\u00e1genes base para varias dependencias. Por ejemplo, una para PostgreSQL<\/a> y otra para Redis<\/a>.<\/li>\nvolumes<\/code><\/a> para persistir los datos en tu m\u00e1quina anfitriona si lo necesitas. Persistir los datos en la m\u00e1quina anfitriona te ayuda a evitar perderlos si se borran los contenedores Docker o si tienes que volver a crearlos.<\/li>\nnetworks<\/code><\/a> para aislar tu configuraci\u00f3n y evitar conflictos de red con el host y otros contenedores. Tambi\u00e9n ayuda a tus contenedores a encontrarse y comunicarse f\u00e1cilmente entre s\u00ed.<\/li>\n<\/ol>\ndocker-compose.yml<\/code> con este aspecto:<\/p>\nversion: '3.8'services:\n db:\n image: postgres:14.7-alpine3.17\n hostname: mk_db\n restart: on-failure\n ports:\n - ${DB_PORT:-5432}:5432\n volumes:\n - db_data:\/var\/lib\/postgresql\/data\n environment:\n POSTGRES_USER: ${DB_USER:-user}\n POSTGRES_PASSWORD: ${DB_PASSWORD:-password}\n POSTGRES_DB: ${DB_NAME:-main}\n networks:\n - mk_network\n redis:\n image: redis:6.2.11-alpine3.17\n hostname: mk_redis\n restart: on-failure\n ports:\n - ${REDIS_PORT:-6379}:6379\n networks:\n - mk_network\n \nvolumes:\n db_data:\n\nnetworks:\n mk_network:\n name: mk_network<\/code><\/pre>\nContenedorizar la Aplicaci\u00f3n<\/h2>\n
Construye una imagen Docker para tu aplicaci\u00f3n<\/h3>\n
Dockerfile<\/code>, y luego llamarla desde docker-compose.yml<\/code>. Para crear tu archivo Dockerfile<\/code>:<\/p>\n\n
FROM node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\narm64-based<\/code> pero necesitas construir una imagen amd64<\/code>. Puedes hacerlo especificando -- platform<\/code> en Dockerfile<\/code>:\nFROM --platform=amd64 node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install \nCOPY . .<\/code><\/pre>\n<\/li>\nDockerfile<\/code> desde docker-compose.yml<\/code>:\nservices:\n ...redis\n ...db\n \n app:\n build:\n context: .\n dockerfile: Dockerfile\n platforms:\n - \"linux\/amd64\"\n command: yarn dev\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n networks:\n - mk_network\n depends_on:\n - redis\n - db<\/code><\/pre>\n<\/li>\nservices:\n ... redis\n ... db\n \n build-docker:\n image: myapp\n build:\n context: .\n dockerfile: Dockerfile\n app:\n image: myapp\n platforms:\n - \"linux\/amd64\"\n command: yarn dev\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n volumes:\n - .:\/opt\/app\n - node_modules:\/opt\/app\/node_modules\n networks:\n - mk_network\n depends_on:\n - redis\n - db\n - build-docker\n \nvolumes:\n node_modules:<\/code><\/pre>\n<\/li>\n<\/ol>\nnode_modules<\/code> tambi\u00e9n se monta expl\u00edcitamente para evitar problemas espec\u00edficos de la plataforma con los paquetes. Significa que en lugar de utilizar el node_modules<\/code> en el host, el contenedor Docker utiliza el suyo propio pero lo mapea en el host en un volumen separado.<\/p>\nConstruye Incrementalmente las Im\u00e1genes de Producci\u00f3n con Integraci\u00f3n Continua<\/h2>\n
Construir las im\u00e1genes Docker<\/h3>\n
Etapa 1: Constructor<\/h4>\n
dist\/<\/code> y copia all\u00ed la versi\u00f3n construida del c\u00f3digo. Pero esta imagen es demasiado grande, con un enorme conjunto de huellas, para utilizarla en producci\u00f3n. Adem\u00e1s, como utilizamos registros NPM privados, tambi\u00e9n utilizamos nuestro NPM_TOKEN<\/code> privado en esta fase. As\u00ed que, definitivamente, no queremos que esta etapa est\u00e9 expuesta al mundo exterior. Lo \u00fanico que necesitamos de esta etapa es la carpeta dist\/<\/code>.<\/p>\nFase 2: Producci\u00f3n<\/h4>\n
NPM_TOKEN<\/code>. As\u00ed que esta etapa todav\u00eda no est\u00e1 lista para ser expuesta. Adem\u00e1s, presta atenci\u00f3n a yarn cache clean<\/code> en la l\u00ednea 19. Ese min\u00fasculo comando reduce el tama\u00f1o de nuestra imagen hasta en un 60%.<\/p>\nEtapa 3: Tiempo de ejecuci\u00f3n<\/h4>\n
NPM_TOKEN<\/code> y s\u00f3lo ejecutamos la aplicaci\u00f3n.<\/p>\nDockerfile.production<\/code> final:<\/p>\n# Stage 1: build the source code \nFROM node:18.15.0-alpine3.17 as builder \nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install \nCOPY . . \nRUN yarn build \n\n# Stage 2: copy the built version and build the production dependencies FROM node:18.15.0-alpine3.17 as production \nWORKDIR \/opt\/app \nCOPY package.json yarn.lock .\/ \nRUN yarn install --production && yarn cache clean \nCOPY --from=builder \/opt\/app\/dist\/ .\/dist\/ \n\n# Stage 3: copy the production ready app to runtime \nFROM node:18.15.0-alpine3.17 as runtime \nWORKDIR \/opt\/app \nCOPY --from=production \/opt\/app\/ . \nCMD [\"yarn\", \"start\"]<\/code><\/pre>\npackage.json<\/code> y yarn.lock<\/code>, instalando las dependencias, y luego copiando el resto de la base de c\u00f3digo. La raz\u00f3n es que Docker construye cada comando como una capa sobre la anterior. Y cada compilaci\u00f3n podr\u00eda utilizar las capas anteriores si est\u00e1n disponibles y s\u00f3lo construir las capas nuevas por motivos de rendimiento.<\/p>\nsrc\/services\/service1.ts<\/code> sin tocar los paquetes. Significa que las cuatro primeras capas de la etapa constructora est\u00e1n intactas y podr\u00edan reutilizarse. Esto hace que el proceso de construcci\u00f3n sea incre\u00edblemente m\u00e1s r\u00e1pido.<\/p>\nEmpujar la aplicaci\u00f3n al Registro de Contenedores de Google a trav\u00e9s de Pipelines CircleCI<\/h3>\n
circleci\/gcp-gcr orbs<\/code>:<\/p>\nexecutors:\n docker-executor:\n docker:\n - image: cimg\/base:2023.03\norbs:\n gcp-gcr: circleci\/gcp-gcr@0.15.1\njobs:\n ...\n deploy:\n description: Build & push image to Google Artifact Registry\n executor: docker-executor\n steps:\n ...\n - gcp-gcr\/build-image:\n image: my-app\n dockerfile: Dockerfile.production\n tag: ${CIRCLE_SHA1:0:7},latest\n - gcp-gcr\/push-image:\n image: my-app\n tag: ${CIRCLE_SHA1:0:7},latest<\/code><\/pre>\nEnviar la aplicaci\u00f3n al Registro de Contenedores de Google mediante acciones de GitHub<\/h3>\n
gcloud<\/code> y creamos y enviamos la imagen Docker a gcr.io<\/code>:<\/p>\njobs:\n setup-build:\n name: Setup, Build\n runs-on: ubuntu-latest\n\n steps:\n - name: Checkout\n uses: actions\/checkout@v3\n\n - name: Get Image Tag\n run: |\n echo \"TAG=$(git rev-parse --short HEAD)\" >> $GITHUB_ENV\n\n - uses: google-github-actions\/setup-gcloud@master\n with:\n service_account_key: ${{ secrets.GCP_SA_KEY }}\n project_id: ${{ secrets.GCP_PROJECT_ID }}\n\n - run: |-\n gcloud --quiet auth configure-docker\n\n - name: Build\n run: |-\n docker build \n --tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\" \n --tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\" \n .\n\n - name: Push\n run: |-\n docker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\"\n docker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\"<\/code><\/pre>\nDesplegar Cambios en el Google Kubernetes Engine Utilizando Google Delivery Pipelines<\/h2>\n
gcloud<\/code>. Echemos un vistazo a ese paso en la tuber\u00eda CircleCI:<\/p>\n- run:\n name: Create new release\n command: gcloud deploy releases create release-${CIRCLE_SHA1:0:7} --delivery-pipeline my-del-pipeline --region $REGION --annotations commitId=$CIRCLE_SHA1 --images my-app=gcr.io\/${PROJECT_ID}\/my-app:${CIRCLE_SHA1:0:7}<\/code><\/pre>\nC\u00f3mo Se Beneficia de este Proceso el Equipo de Control de Calidad<\/h2>\n
services:\n ...redis\n ...db\n \n app:\n image: gcr.io\/${PROJECT_ID}\/my-app:latest\n restart: on-failure\n ports:\n - ${PORT:-4000}:${PORT:-4000}\n environment:\n - NODE_ENV=production\n - REDIS_URL=redis:\/\/redis:6379\n - DATABASE_URL=postgresql:\/\/${DB_USER:-user}:${DB_PASSWORD:-password}@db:5432\/main\n networks:\n - mk_network\n depends_on:\n - redis\n - db<\/code><\/pre>\ndocker compose up<\/code><\/pre>\nVentajas del Uso de Docker<\/h2>\n