Chez Kinsta, nous avons des projets de toutes tailles pour l’h\u00e9bergement d’applications, l’h\u00e9bergement de bases de donn\u00e9es et l’h\u00e9bergement WordPress infog\u00e9r\u00e9.<\/p>\n
Avec les solutions d’h\u00e9bergement cloud de Kinsta, vous pouvez d\u00e9ployer des applications<\/a> dans un certain nombre de langages et de frameworks, tels que NodeJS, PHP, Ruby, Go, Scala et Python. Avec un fichier Docker, vous pouvez d\u00e9ployer n’importe quelle application. Vous pouvez connecter votre d\u00e9p\u00f4t Git (h\u00e9berg\u00e9 sur GitHub, GitLab ou Bitbucket) pour d\u00e9ployer votre code directement sur Kinsta.<\/p>\n Vous pouvez h\u00e9berger des bases de donn\u00e9es MariaDB, Redis, MySQL et PostgreSQL<\/a> pr\u00eates \u00e0 l’emploi, ce qui vous permet de vous concentrer sur le d\u00e9veloppement de vos applications plut\u00f4t que de vous pr\u00e9occuper des configurations d’h\u00e9bergement.<\/p>\n Et si vous choisissez notre h\u00e9bergement WordPress infog\u00e9r\u00e9<\/a>, vous b\u00e9n\u00e9ficiez de la puissance des machines Google Cloud C2 sur leur r\u00e9seau Premium et de la s\u00e9curit\u00e9 int\u00e9gr\u00e9e Cloudflare, ce qui fait de vos sites WordPress les plus rapides et les plus s\u00fbrs du march\u00e9. L’un des plus grands d\u00e9fis du d\u00e9veloppement et de la maintenance d’applications cloud-natives au niveau de l’entreprise est d’avoir une exp\u00e9rience coh\u00e9rente tout au long du cycle de d\u00e9veloppement. C’est encore plus difficile pour les entreprises distantes avec des \u00e9quipes distribu\u00e9es travaillant sur diff\u00e9rentes plateformes, avec des configurations diff\u00e9rentes et une communication asynchrone. Nous devons fournir une solution coh\u00e9rente, fiable et \u00e9volutive qui fonctionne pour :<\/p>\n Chez Kinsta, nous nous appuyons fortement sur Docker<\/a> pour cette exp\u00e9rience coh\u00e9rente \u00e0 chaque \u00e9tape, du d\u00e9veloppement \u00e0 la production. Dans cet article, nous vous guidons \u00e0 travers :<\/p>\n L’ex\u00e9cution d’une application en local exige que les d\u00e9veloppeurs pr\u00e9parent m\u00e9ticuleusement l’environnement, installent toutes les d\u00e9pendances, configurent les serveurs et les services et s’assurent qu’ils sont correctement configur\u00e9s. Lorsque vous ex\u00e9cutez plusieurs applications, cela peut s’av\u00e9rer fastidieux, en particulier lorsqu’il s’agit de projets complexes comportant de nombreuses d\u00e9pendances. Lorsque vous ajoutez \u00e0 cette variable plusieurs contributeurs disposant de plusieurs syst\u00e8mes d’exploitation, le chaos s’installe. Pour l’\u00e9viter, nous utilisons Docker.<\/p>\n Avec Docker, vous pouvez d\u00e9clarer les configurations de l’environnement, installer les d\u00e9pendances et construire des images avec tout ce qu’il faut l\u00e0 o\u00f9 il faut. N’importe qui, n’importe o\u00f9, avec n’importe quel syst\u00e8me d’exploitation peut utiliser les m\u00eames images et avoir exactement la m\u00eame exp\u00e9rience que les autres.<\/p>\n Pour commencer, cr\u00e9ez un fichier Docker Compose<\/a>, Les fichiers Docker Compose sont tr\u00e8s utiles lorsque plusieurs conteneurs sont en cours d’ex\u00e9cution et qu’il existe des d\u00e9pendances entre les conteneurs.<\/p>\n Pour cr\u00e9er votre fichier En r\u00e9unissant tous ces \u00e9l\u00e9ments, nous obtenons un site Tout d’abord, nous devons cr\u00e9er une image Docker \u00e0 l’aide de Pour cr\u00e9er votre fichier Conseil de pro : Notez que La majorit\u00e9 de nos applications et services utilisent CI\/CD pour le d\u00e9ploiement. Docker joue un r\u00f4le important dans ce processus. Chaque changement dans la branche principale d\u00e9clenche imm\u00e9diatement un pipeline de construction via GitHub Actions ou CircleCI. Le flux de travail g\u00e9n\u00e9ral est tr\u00e8s simple : il installe les d\u00e9pendances, ex\u00e9cute les tests, construit l’image Docker, et la pousse vers Google Container Registry (ou Artifact Registry). La partie dont nous parlons dans cet article est l’\u00e9tape de construction.<\/p>\n Nous utilisons des constructions en plusieurs \u00e9tapes pour des raisons de s\u00e9curit\u00e9 et de performance.<\/p>\n Dans cette \u00e9tape, nous copions la base de code enti\u00e8re avec toutes les sources et la configuration, nous installons toutes les d\u00e9pendances, y compris les d\u00e9pendances de d\u00e9veloppement, et nous construisons l’application. Elle cr\u00e9e un dossier La plupart des gens utilisent cette \u00e9tape pour l’ex\u00e9cution car elle est tr\u00e8s proche de ce dont nous avons besoin pour faire fonctionner l’application. Cependant, nous devons encore installer les d\u00e9pendances de production, ce qui signifie que nous laissons des traces et que nous avons besoin du dossier La derni\u00e8re \u00e9tape doit \u00eatre aussi fine que possible avec un minimum d’empreinte. Nous nous contentons donc de copier l’application toute pr\u00eate de la production et de passer \u00e0 autre chose. Nous laissons tous ces trucs yarn et C’est la version finale de Notez que, pour toutes les \u00e9tapes, nous commen\u00e7ons par copier les fichiers Supposons que vous ayez modifi\u00e9 quelque chose dans Il y a plusieurs fa\u00e7ons de construire une image Docker dans les pipelines CircleCI. Dans notre cas, nous avons choisi d’utiliser Une configuration minimale est n\u00e9cessaire pour construire et pousser notre application, gr\u00e2ce \u00e0 Docker.<\/p>\n Comme alternative \u00e0 CircleCI, nous pouvons utiliser GitHub Actions pour d\u00e9ployer l’application en continu. Nous configurons \u00c0 chaque petite modification apport\u00e9e \u00e0 la branche principale, nous construisons et poussons une nouvelle image Docker vers le registre.<\/p>\n Le fait de disposer d’images Docker pr\u00eates \u00e0 l’emploi pour chaque modification facilite \u00e9galement le d\u00e9ploiement en production ou le retour en arri\u00e8re en cas de probl\u00e8me. Nous utilisons Google Kubernetes Engine pour g\u00e9rer et servir nos applications et nous utilisons Google Cloud Deploy et Delivery Pipelines pour notre processus de d\u00e9ploiement continu.<\/p>\n Lorsque l’image Docker est construite apr\u00e8s chaque petite modification (avec le pipeline CI illustr\u00e9 ci-dessus), nous allons plus loin et d\u00e9ployons la modification sur notre cluster de d\u00e9veloppement \u00e0 l’aide de Cela d\u00e9clenche un processus de lib\u00e9ration pour d\u00e9ployer les changements dans notre cluster Kubernetes de d\u00e9veloppement. Apr\u00e8s avoir test\u00e9 et obtenu les approbations, nous promouvons le changement vers staging et ensuite vers production. Tout cela est possible parce que nous disposons d’une image Docker isol\u00e9e pour chaque changement, qui contient presque tout ce dont elle a besoin. Il nous suffit d’indiquer au d\u00e9ploiement quelle balise utiliser.<\/p>\n L’\u00e9quipe d’assurance qualit\u00e9 a surtout besoin d’une version cloud de pr\u00e9-production des applications \u00e0 tester. Cependant, elle a parfois besoin d’ex\u00e9cuter localement une application pr\u00e9construite (avec toutes les d\u00e9pendances) pour tester une certaine fonctionnalit\u00e9. Dans ces cas, ils ne veulent pas ou n’ont pas besoin de passer par la douleur de cloner le projet entier, d’installer les paquets npm, de construire l’application, de faire face aux erreurs des d\u00e9veloppeurs, et de revoir tout le processus de d\u00e9veloppement pour que l’application soit op\u00e9rationnelle. Maintenant que tout est d\u00e9j\u00e0 disponible en tant qu’image Docker sur Google Container Registry, tout ce dont ils ont besoin, c’est d’un service dans le fichier Docker compose :<\/p>\n Gr\u00e2ce \u00e0 ce service, ils peuvent lancer l’application sur leurs machines locales \u00e0 l’aide de conteneurs Docker :<\/p>\n Il s’agit l\u00e0 d’un grand pas vers la simplification des processus de test. M\u00eame si l’assurance qualit\u00e9 d\u00e9cide de tester un tag sp\u00e9cifique de l’application, elle peut facilement changer le tag de l’image \u00e0 la ligne 6 et r\u00e9ex\u00e9cuter la commande Docker Composer. M\u00eame s’ils d\u00e9cident de comparer simultan\u00e9ment diff\u00e9rentes versions de l’application, ils peuvent facilement y parvenir avec quelques ajustements. Le plus grand avantage est de tenir notre \u00e9quipe d’assurance qualit\u00e9 \u00e0 l’\u00e9cart des d\u00e9fis des d\u00e9veloppeurs.<\/p>\n
\nSurmonter le d\u00e9fi du d\u00e9veloppement d’applications Cloud-Natives au sein d’une \u00e9quipe distribu\u00e9e<\/h2>\n
\n
\n
Utilisation de Docker Desktop pour am\u00e9liorer l’exp\u00e9rience des d\u00e9veloppeurs<\/h2>\n
D\u00e9clarer votre configuration avec Docker Compose<\/h2>\n
docker-compose.yml<\/code>. Il s’agit d’un fichier de configuration d\u00e9claratif \u00e9crit au format YAML qui indique \u00e0 Docker l’\u00e9tat souhait\u00e9 de votre application. Docker utilise ces informations pour configurer l’environnement de votre application.<\/p>\ndocker-compose.yml<\/code>:<\/p>\n\n
image<\/code><\/a> comme base de notre application. Recherchez sur Docker Hub et essayez de trouver une image Docker qui contient d\u00e9j\u00e0 les d\u00e9pendances de votre application. Veillez \u00e0 utiliser une balise d’image sp\u00e9cifique pour \u00e9viter les erreurs. L’utilisation de la balise latest<\/code> peut provoquer des erreurs impr\u00e9vues dans votre application. Vous pouvez utiliser plusieurs images de base pour plusieurs d\u00e9pendances. Par exemple, une pour PostgreSQL<\/a> et une pour Redis<\/a>.<\/li>\nvolumes<\/code><\/a> pour persister les donn\u00e9es sur votre h\u00f4te si vous en avez besoin. La persistance des donn\u00e9es sur la machine h\u00f4te vous permet d’\u00e9viter de perdre des donn\u00e9es si les conteneurs Docker sont supprim\u00e9s ou si vous devez les recr\u00e9er.<\/li>\nnetworks<\/code><\/a> pour isoler votre installation afin d’\u00e9viter les conflits de r\u00e9seau avec l’h\u00f4te et les autres conteneurs. Cela permet \u00e9galement \u00e0 vos conteneurs de se retrouver facilement et de communiquer entre eux.<\/li>\n<\/ol>\ndocker-compose.yml<\/code> qui ressemble \u00e0 ceci :<\/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>\nConteneuriser l’application<\/h2>\n
Construire une image Docker pour votre application<\/h3>\n
Dockerfile<\/code>, puis l’appeler \u00e0 partir de docker-compose.yml<\/code>.<\/p>\nDockerfile<\/code>:<\/p>\n\n
FROM node:18.15.0-alpine3.17\n<\/code><\/pre>\n<\/li>\narm64-based<\/code> mais que vous deviez construire une image amd64<\/code>. Vous pouvez le faire en sp\u00e9cifiant -- platform<\/code> dans 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> \u00e0 partir de 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> est \u00e9galement mont\u00e9 explicitement pour \u00e9viter les probl\u00e8mes de paquets sp\u00e9cifiques \u00e0 la plate-forme. Cela signifie qu’au lieu d’utiliser le site node_modules<\/code> sur l’h\u00f4te, le conteneur docker utilise le sien mais le mappe sur l’h\u00f4te dans un volume s\u00e9par\u00e9.<\/p>\nConstruire progressivement les images de production avec l’int\u00e9gration continue<\/h2>\n
Construction des images Docker<\/h3>\n
\u00c9tape 1 : Construction<\/h4>\n
dist\/<\/code> et y copie la version construite du code. Mais cette image est beaucoup trop volumineuse et comporte un grand nombre d’empreintes pour \u00eatre utilis\u00e9e en production. De plus, comme nous utilisons des registres NPM priv\u00e9s, nous utilisons \u00e9galement notre site priv\u00e9 NPM_TOKEN<\/code> \u00e0 ce stade. Nous ne voulons donc pas que cette \u00e9tape soit expos\u00e9e au monde ext\u00e9rieur. La seule chose dont nous avons besoin \u00e0 ce stade est le dossier dist\/<\/code>.<\/p>\n\u00c9tape 2 : Production<\/h4>\n
NPM_TOKEN<\/code>. Cette \u00e9tape n’est donc pas encore pr\u00eate \u00e0 \u00eatre expos\u00e9e. Faites \u00e9galement attention \u00e0 yarn cache clean<\/code> sur la ligne 19. Cette petite commande r\u00e9duit la taille de notre image de 60 %.<\/p>\n\u00c9tape 3 : Ex\u00e9cution<\/h4>\n
NPM_TOKEN<\/code> derri\u00e8re nous et n’ex\u00e9cutons que l’application.<\/p>\nDockerfile.production<\/code>:<\/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> et yarn.lock<\/code>, nous installons les d\u00e9pendances, puis nous copions le reste de la base de code. La raison en est que Docker construit chaque commande comme une couche au-dessus de la pr\u00e9c\u00e9dente. Et chaque compilation peut utiliser les couches pr\u00e9c\u00e9dentes si elles sont disponibles et ne construire les nouvelles couches qu’\u00e0 des fins de performance.<\/p>\nsrc\/services\/service1.ts<\/code> sans toucher aux paquets. Cela signifie que les quatre premi\u00e8res couches de l’\u00e9tape de construction sont intactes et peuvent \u00eatre r\u00e9utilis\u00e9es. Cela rend le processus de construction incroyablement plus rapide.<\/p>\nPousser l’application vers le registre de conteneurs de Google via les 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>\nPousser l’application vers le Google Container Registry via les actions GitHub<\/h3>\n
gcloud<\/code> et construisons et poussons l’image Docker vers 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>\nD\u00e9ploiement de modifications sur le moteur Google Kubernetes \u00e0 l’aide de Google Delivery Pipelines<\/h2>\n
gcloud<\/code>. Jetons un coup d’\u0153il \u00e0 cette \u00e9tape dans le pipeline 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>\nComment l’\u00e9quipe d’assurance qualit\u00e9 b\u00e9n\u00e9ficie de ce processus<\/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>\nAvantages de l’utilisation de Docker<\/h2>\n