In Kinsta abbiamo progetti di tutte le dimensioni per l’Hosting di Applicazioni, l’Hosting di Database e l’Hosting WordPress Gestito.<\/p>\n
Con le soluzioni di cloud hosting di Kinsta, si possono distribuire applicazioni<\/a> in diversi linguaggi e framework, come NodeJS, PHP, Ruby, Go, Scala e Python. Con un file Docker, potrete distribuire qualsiasi applicazione. Potete collegare il vostro repository Git (ospitato su GitHub, GitLab o Bitbucket) per distribuire il codice direttamente su Kinsta.<\/p>\n Potete ospitare i database MariaDB, Redis, MySQL e PostgreSQL<\/a> in modo immediato, risparmiando tempo per concentrarvi sullo sviluppo delle vostre applicazioni piuttosto che sulle configurazioni di hosting.<\/p>\n Inoltre, se scegliete il nostro Hosting WordPress Gestito<\/a>, potrete usufruire della potenza delle macchine di Google Cloud C2 sulla loro rete di livello Premium e della sicurezza integrata in Cloudflare, rendendo i vostri siti web WordPress i pi\u00f9 veloci e sicuri del mercato. Una delle sfide pi\u00f9 grandi dello sviluppo e della manutenzione di applicazioni cloud-native a livello aziendale \u00e8 quella di avere un’esperienza coerente durante l’intero ciclo di vita dello sviluppo. Questo \u00e8 ancora pi\u00f9 difficile per le aziende remote con team distribuiti che lavorano su piattaforme diverse, con configurazioni diverse e comunicazioni asincrone. Dobbiamo fornire una soluzione coerente, affidabile e scalabile che funzioni per:<\/p>\n In Kinsta, ci affidiamo molto a Docker<\/a> per ottenere un’esperienza coerente in ogni fase, dallo sviluppo alla produzione. In questo post vedremo:<\/p>\n L’esecuzione di un’applicazione in locale richiede che gli sviluppatori preparino meticolosamente l’ambiente, installino tutte le dipendenze, impostino i server e i servizi e si assicurino che siano configurati correttamente. Quando si eseguono pi\u00f9 applicazioni, tutto questo pu\u00f2 essere complicato, soprattutto quando si tratta di progetti complessi con molteplici dipendenze. Quando a questa variabile si aggiungono pi\u00f9 collaboratori con pi\u00f9 sistemi operativi, si scatena il caos. Per evitarlo, usiamo Docker.<\/p>\n Con Docker si possono dichiarare le configurazioni dell’ambiente, installare le dipendenze e creare immagini con ogni cosa al suo posto. Chiunque, ovunque, con qualsiasi sistema operativo, pu\u00f2 usare le stesse immagini e avere la stessa esperienza di tutti gli altri.<\/p>\n Per iniziare, creiamo un file Docker Compose<\/a>, I file Docker Compose sono molto utili quando si ha pi\u00f9 di un container in esecuzione e ci sono dipendenze tra i container.<\/p>\n Per creare il file Riunendo il tutto, abbiamo un Per prima cosa, dobbiamo creare un’immagine Docker utilizzando Per creare il Suggerimento: La maggior parte delle applicazioni e dei servizi usa la CI\/CD per la distribuzione. Docker svolge un ruolo importante in questo processo. Ogni modifica apportata al branch principale attiva immediatamente una pipeline di build attraverso GitHub Actions o CircleCI. Il flusso di lavoro generale \u00e8 molto semplice: installa le dipendenze, esegue i test, costruisce l’immagine docker e la invia al Google Container Registry (o Artifact Registry). La parte di cui parliamo in questo articolo \u00e8 la fase di build.<\/p>\n Per motivi di sicurezza e di prestazioni, usiamo build in pi\u00f9 fasi.<\/p>\n In questa fase copiamo l’intero codice base con tutti i sorgenti e la configurazione, installiamo tutte le dipendenze, comprese quelle di dev, e costruiamo l’applicazione. Viene creata una cartella La maggior parte delle persone usa questo stage per il runtime perch\u00e9 \u00e8 molto vicino a ci\u00f2 che serve per far funzionare l’applicazione. Tuttavia, dobbiamo ancora installare le dipendenze di produzione e questo significa che lasciamo delle impronte e abbiamo bisogno di L’ultimo stadio deve essere il pi\u00f9 sottile possibile e con un’impronta minima. Per questo motivo, copiamo l’applicazione gi\u00e0 pronta dalla produzione e andiamo avanti. Lasciamo da parte tutte le cose di yarn e Questa \u00e8 la versione finale di Notate che, per tutte le fasi, iniziamo a copiare prima i file Supponiamo di aver cambiato qualcosa in Esistono diversi modi per creare un’immagine Docker nelle pipeline di CircleCI. Nel nostro caso, abbiamo scelto di usare Grazie a Docker, la configurazione necessaria per creare e inviare la nostra applicazione \u00e8 minima.<\/p>\n In alternativa a CircleCI, possiamo usare GitHub Actions per distribuire l’applicazione in modo continuo. Configuriamo A ogni piccola modifica apportata al branch principale, effettuiamo build e push di una nuova immagine Docker nel registro.<\/p>\n Avere immagini Docker pronte all’uso per ogni singola modifica rende pi\u00f9 facile il deploy in produzione o il rollback nel caso in cui qualcosa vada storto. Usiamo Google Kubernetes Engine per gestire e servire le nostre applicazioni e usiamo Google Cloud Deploy e Delivery Pipelines per il nostro processo di distribuzione continua.<\/p>\n Quando l’immagine Docker viene costruita dopo ogni piccola modifica (con la pipeline CI mostrata sopra) facciamo un ulteriore passo avanti e distribuiamo la modifica al nostro cluster di sviluppo utilizzando In questo modo si attiva un processo di rilascio per distribuire le modifiche nel nostro cluster Kubernetes di sviluppo. Dopo aver testato e ottenuto le approvazioni, promuoviamo la modifica a staging e poi a produzione. Tutto questo \u00e8 possibile perch\u00e9 per ogni modifica abbiamo un’immagine Docker isolata e sottile che contiene quasi tutto ci\u00f2 di cui ha bisogno. Dobbiamo solo indicare al deployment quale tag usare.<\/p>\n Il team QA ha bisogno soprattutto di una versione cloud di pre-produzione delle applicazioni da testare. Tuttavia, a volte ha bisogno di eseguire un’app precostruita in locale (con tutte le dipendenze) per testare una determinata funzionalit\u00e0. In questi casi, non vogliono o non hanno bisogno di affrontare la clonazione dell’intero progetto, l’installazione dei pacchetti npm, la creazione dell’app, gli errori dello sviluppatore e l’intero processo di sviluppo per rendere l’app operativa. Ora che tutto \u00e8 gi\u00e0 disponibile come immagine Docker su Google Container Registry, tutto ci\u00f2 che serve \u00e8 un servizio nel file Docker compose:<\/p>\n Con questo servizio, possono avviare l’applicazione sulle loro macchine locali usando i container Docker:<\/p>\n Questo \u00e8 un enorme passo avanti verso la semplificazione dei processi di testing. Anche se il QA decide di testare un tag specifico dell’applicazione, pu\u00f2 facilmente cambiare il tag dell’immagine alla riga 6 ed eseguire nuovamente il comando Docker compose. Anche se decidono di confrontare simultaneamente diverse versioni dell’app, possono farlo facilmente con poche modifiche. Il vantaggio pi\u00f9 grande \u00e8 quello di tenere il nostro team di QA lontano dalle sfide degli sviluppatori.<\/p>\n
\nSuperare la sfida dello sviluppo di applicazioni cloud-native in un team distribuito<\/h2>\n
\n
\n
Usare Docker Desktop per migliorare l’esperienza di sviluppo<\/h2>\n
Dichiarare la configurazione con Docker Compose<\/h2>\n
docker-compose.yml<\/code>. Si tratta di un file di configurazione dichiarativo scritto in formato YAML che indica a Docker lo stato desiderato dell’applicazione. Docker usa queste informazioni per configurare l’ambiente per l’applicazione.<\/p>\ndocker-compose.yml<\/code>:<\/p>\n\n
image<\/code><\/a> come base per la nostra applicazione. Cerchiamo su Docker Hub e cerchiamo di trovare un’immagine Docker che contenga gi\u00e0 le dipendenze dell’applicazione. Assicuriamoci di usare un tag immagine specifico per evitare errori. L’utilizzo del tag latest<\/code> pu\u00f2 causare errori imprevisti nell\u2019applicazione. Possiamo usare pi\u00f9 immagini di base per pi\u00f9 dipendenze. Per esempio, una per PostgreSQL<\/a> e una per Redis<\/a>.<\/li>\nvolumes<\/code><\/a> per persistere i dati sull’host, se necessario. La persistenza dei dati sul computer host aiuta a non perdere i dati se i container docker vengono cancellati o se \u00e8 necessario ricrearli.<\/li>\nnetworks<\/code><\/a> per isolare la configurazione ed evitare conflitti di rete con l’host e gli altri container. Inoltre, aiutiamo i nostri container a trovarsi e a comunicare facilmente tra loro.<\/li>\n<\/ol>\ndocker-compose.yml<\/code> che si presenta in questo modo:<\/p>\nversion: '3.8'services:\n db:\n\timage: postgres:14.7-alpine3.17\n\thostname: mk_db\n\trestart: on-failure\n\tports:\n \t- ${DB_PORT:-5432}:5432\n\tvolumes:\n \t- db_data:\/var\/lib\/postgresql\/data\n\tenvironment:\n \tPOSTGRES_USER: ${DB_USER:-user}\n \tPOSTGRES_PASSWORD: ${DB_PASSWORD:-password}\n \tPOSTGRES_DB: ${DB_NAME:-main}\n\tnetworks:\n \t- mk_network\n redis:\n\timage: redis:6.2.11-alpine3.17\n\thostname: mk_redis\n\trestart: on-failure\n\tports:\n \t- ${REDIS_PORT:-6379}:6379\n\tnetworks:\n \t- mk_network\n \t \nvolumes:\n db_data:\n\nnetworks:\n mk_network:\n\tname: mk_network<\/code><\/pre>\nContainerizzare l’applicazione<\/h2>\n
Creare un’immagine Docker per l’applicazione<\/h3>\n
Dockerfile<\/code> e poi richiamarla da 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> ma di dover creare un’immagine amd64<\/code>. Possiamo farlo specificando -- platform<\/code> in 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> da docker-compose.yml<\/code>:\nservices:\n ...redis\n ...db\n \n app:\n\tbuild:\n \tcontext: .\n \tdockerfile: Dockerfile\n\tplatforms:\n \t- \"linux\/amd64\"\n\tcommand: yarn dev\n\trestart: on-failure\n\tports:\n \t- ${PORT:-4000}:${PORT:-4000}\n\tnetworks:\n \t- mk_network\n\tdepends_on:\n \t- redis\n \t- db<\/code><\/pre>\n<\/li>\nservices:\n ... redis\n ... db\n \n build-docker:\n\timage: myapp\n\tbuild:\n \tcontext: .\n \tdockerfile: Dockerfile\n app:\n\timage: myapp\n\tplatforms:\n \t- \"linux\/amd64\"\n\tcommand: yarn dev\n\trestart: on-failure\n\tports:\n \t- ${PORT:-4000}:${PORT:-4000}\n\tvolumes:\n \t- .:\/opt\/app\n \t- node_modules:\/opt\/app\/node_modules\n\tnetworks:\n \t- mk_network\n\tdepends_on:\n \t- redis\n \t- db\n \t- build-docker\n \t \nvolumes:\n node_modules:<\/code><\/pre>\n<\/li>\n<\/ol>\nnode_modules<\/code> viene montato esplicitamente per evitare problemi specifici della piattaforma con i pacchetti. Ci\u00f2 significa che invece di usare node_modules<\/code> sull’host, il contenitore docker usa il proprio ma lo mappa sull’host in un volume separato.<\/p>\nCostruire in modo incrementale le immagini di produzione con l’integrazione continua<\/h2>\n
Creazione delle immagini Docker<\/h3>\n
Fase 1: Costruttore<\/h4>\n
dist\/<\/code> e in cui si copia la versione costruita del codice. Ma questa immagine \u00e8 troppo grande, con un’enorme serie di impronte, per essere utilizzata in produzione. Inoltre, dato che ci serviamo di registri NPM privati, usiamo anche il nostro NPM_TOKEN<\/code> privato in questa fase. Quindi, non vogliamo assolutamente che questo stadio sia esposto al mondo esterno. L’unica cosa di cui abbiamo bisogno in questa fase \u00e8 la cartella dist\/<\/code>.<\/p>\nFase 2: Produzione<\/h4>\n
NPM_TOKEN<\/code>. Quindi questo stadio non \u00e8 ancora pronto per essere esposto. Merita inoltre particolare attenzione yarn cache clean<\/code> alla riga 19. Questo piccolo comando riduce le dimensioni della nostra immagine fino al 60%.<\/p>\nFase 3: Runtime<\/h4>\n
NPM_TOKEN<\/code> ed eseguiamo solo l’applicazione.<\/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> e yarn.lock<\/code>, installiamo le dipendenze e poi copiamo il resto del codice base. Il motivo \u00e8 che Docker costruisce ogni comando come un livello superiore al precedente. Ogni build pu\u00f2 usare i livelli precedenti, se disponibili, e costruire solo i nuovi livelli per motivi di prestazioni.<\/p>\nsrc\/services\/service1.ts<\/code> senza toccare i pacchetti. Ci\u00f2 significa che i primi quattro livelli dello stage del builder non sono stati toccati e possono essere riutilizzati. Questo rende il processo di build incredibilmente pi\u00f9 veloce.<\/p>\nInviare l’app al registro dei container di Google attraverso le pipeline di CircleCI<\/h3>\n
circleci\/gcp-gcr orbs<\/code>:<\/p>\nexecutors:\n docker-executor:\n docker:\n \t- image: cimg\/base:2023.03\norbs:\n gcp-gcr: circleci\/gcp-gcr@0.15.1\njobs:\n ...\n deploy:\n\tdescription: Build & push image to Google Artifact Registry\n\texecutor: docker-executor\n\tsteps:\n \t...\n \t- gcp-gcr\/build-image:\n \timage: my-app\n \tdockerfile: Dockerfile.production\n \ttag: ${CIRCLE_SHA1:0:7},latest\n \t- gcp-gcr\/push-image:\n \timage: my-app\n \ttag: ${CIRCLE_SHA1:0:7},latest<\/code><\/pre>\nEseguire il push dell’app nel registro di Google Container attraverso le azioni di GitHub<\/h3>\n
gcloud<\/code>, eseguiamo la build e poi il push dell’immagine Docker su 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 \techo \"TAG=$(git rev-parse --short HEAD)\" >> $GITHUB_ENV\n\n - uses: google-github-actions\/setup-gcloud@master\n \twith:\n \tservice_account_key: ${{ secrets.GCP_SA_KEY }}\n \tproject_id: ${{ secrets.GCP_PROJECT_ID }}\n\n - run: |-\n \tgcloud --quiet auth configure-docker\n\n - name: Build\n run: |-\n \tdocker build\n \t--tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\"\n \t--tag \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\"\n \t.\n\n - name: Push\n run: |-\n \tdocker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:$TAG\"\n \tdocker push \"gcr.io\/${{ secrets.GCP_PROJECT_ID }}\/my-app:latest\"<\/code><\/pre>\nDistribuire le modifiche a Google Kubernetes Engine utilizzando le Delivery Pipeline di Google<\/h2>\n
gcloud<\/code>. Diamo un’occhiata a questa fase della pipeline CircleCI:<\/p>\n- run:\n\tname: Create new release\n\tcommand: 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>\nCome il team di Quality Assurance (QA) trae vantaggio da questo processo<\/h2>\n
services:\n ...redis\n ...db\n \n app:\n\timage: gcr.io\/${PROJECT_ID}\/my-app:latest\n\trestart: on-failure\n\tports:\n \t- ${PORT:-4000}:${PORT:-4000}\n\tenvironment:\n \t- NODE_ENV=production\n \t- REDIS_URL=redis:\/\/redis:6379\n \t- DATABASE_URL=postgresql:\/\/${DB_USER:-user}:${DB_PASSWORD:-password}@db:5432\/main\n\tnetworks:\n \t- mk_network\n\tdepends_on:\n \t- redis\n \t- db<\/code><\/pre>\ndocker compose up<\/code><\/pre>\nVantaggi dell’uso di Docker<\/h2>\n