Python: Utilizzi avanzati

Approfondire i tuoi deployment Python

👋 Benvenuti nella documentazione di Stackhero!

Stackhero offre una soluzione cloud Python pronta all'uso che fornisce numerosi vantaggi, tra cui:

  • Distribuisci la tua applicazione in pochi secondi con un semplice git push.
  • Usa il tuo nome di dominio e beneficia della configurazione automatica dei certificati HTTPS per una sicurezza migliorata.
  • Goditi la tranquillità con backup automatici, aggiornamenti con un clic, e una tariffazione semplice, trasparente e prevedibile.
  • Ottieni prestazioni ottimali e una sicurezza robusta grazie a una VM privata e dedicata.

Risparmia tempo e semplificati la vita: ci vogliono solo 5 minuti per provare la soluzione di hosting cloud Python di Stackhero!

Distribuire un branch diverso da main

Fino ad ora, abbiamo utilizzato il comando git push stackhero main per distribuire il branch main in produzione.

Se hai bisogno di distribuire un altro branch, puoi usare questo comando dove <BRANCH> è il nome del branch che desideri distribuire:

git push stackhero <BRANCH>:main

Ad esempio, se vuoi distribuire il branch production, esegui semplicemente:

git push stackhero production:main

Distribuire un tag invece di un branch

Puoi scegliere di distribuire un tag piuttosto che un branch. Per distribuire un tag specifico, sostituisci <TAG> con il tag desiderato nel comando seguente:

git push stackhero '<TAG>^{}:main'

Ad esempio, per distribuire il tag v1.0.0, esegui:

git push stackhero 'v1.0.0^{}:main'

La sintassi ^{} assicura che stai inviando il commit taggato piuttosto che il riferimento del tag stesso.

Distribuire un commit specifico

Oltre a distribuire branch o tag, puoi anche distribuire un commit specifico utilizzando il suo hash. Sostituisci <COMMIT_HASH> con l'hash del commit che desideri distribuire:

git push -f stackhero <COMMIT_HASH>:main

Ad esempio, per distribuire il commit con l'hash abcde, esegui:

git push -f stackhero abcde:main

Tornare a una versione precedente

Se un recente deployment ha introdotto problemi, puoi tornare a un commit precedente distribuendo quel commit. Prima, identifica l'hash del commit eseguendo:

git log

Questo comando mostra la data, l'hash e la descrizione di ogni commit.

Ad esempio, l'output potrebbe apparire così:

git log

commit cccc8b3ebdccb9abc1926ef49ee589dae5c5fe06 (HEAD -> main, stackhero/main)
Author: Developer
Date:   Fri Apr 28 09:36:18 +0000

    Break the code

commit bbbb622301772072c3d82f3cc0d91e29e6e84901
Author: Developer
Date:   Wed Apr 26 12:49:28 +0000

    Update the code

commit aaaa1d8b06535b413e0df8298ccf52339dfef3ff
Author: Developer
Date:   Wed Apr 26 12:44:50 +0000

    Improve the code

Se l'attuale deployment in produzione è il commit "Break the code" (hash che inizia con cccc), e desideri tornare al commit precedente "Update the code" (hash che inizia con bbbb), esegui:

git push -f stackhero bbbb622301772072c3d82f3cc0d91e29e6e84901:main

Per evitare di distribuire codice difettoso e aumentare la stabilità della tua produzione, è altamente raccomandato avere un ambiente di "staging".

Situato tra sviluppo e produzione, l'ambiente di staging fornisce una replica quasi identica della configurazione di produzione. Ti aiuta a testare il tuo codice in modo approfondito prima di un deployment live.

Utilizzare lo staging aumenta la tua fiducia nella funzionalità e nelle prestazioni del tuo codice, risultando in un deployment in produzione più robusto.

Questo tipo di ambiente sarà discusso più avanti nella documentazione.

Configurare un ambiente di staging

Un ambiente di staging è una buona pratica quando viene utilizzato insieme agli ambienti di sviluppo e produzione. Replica l'ambiente di produzione in modo che tu possa testare aggiornamenti e modifiche prima di andare live, riducendo il rischio di problemi in produzione.

Un ambiente di staging deve rispecchiare da vicino l'ambiente di produzione.

Tuttavia, dovrebbe utilizzare una versione clonata del tuo database di produzione o dei servizi connessi piuttosto che il database di produzione live.

Se il tuo servizio Python dipende da database o altri servizi, ricreali in un nuovo stack <Project> - Staging.

Segui questi passaggi per configurare un ambiente di staging con Stackhero:

  1. Sul dashboard di Stackhero, rinomina il tuo stack esistente da <Project> a <Project> - Production. Ad esempio, se il tuo progetto si chiama Chat Bot, lo stack diventa Chat Bot - Production.
  2. Crea un nuovo stack chiamato <Project> - Staging. Per il progetto Chat Bot, lo stack diventa Chat Bot - Staging.
  3. Avvia un servizio Python all'interno dello stack di staging.
  4. Recupera il comando git remote e segui le istruzioni nella documentazione Distribuire nell'ambiente di staging.

Questa configurazione ti assicura di avere un ambiente di staging completamente funzionale per testare gli aggiornamenti prima del deployment in produzione.

Distribuire nell'ambiente di staging

È altamente raccomandato mantenere ambienti di staging e produzione separati. Per gestire più ambienti, inizia rinominando il repository remoto attuale. Ad esempio, rinomina il remoto stackhero in stackhero-production con:

git remote rename stackhero stackhero-production

Successivamente, crea un nuovo servizio Python per il tuo ambiente di staging. Recupera il comando git remote add e modificalo sostituendo <XXXXXX> con il dominio del tuo servizio:

  • Comando originale:

    git remote add stackhero ssh://stackhero@<XXXXXX>.stackhero-network.com:222/project.git

  • Comando modificato:

    git remote add stackhero-staging ssh://stackhero@<XXXXXX>.stackhero-network.com:222/project.git

Puoi quindi distribuire su entrambi gli ambienti utilizzando i seguenti comandi:

  • Distribuire su staging:

    git push stackhero-staging main

  • Distribuire su produzione:

    git push stackhero-production main

Per migliorare il processo di deployment, suggeriamo di utilizzare la versione migliorata del Makefile.

Con questo Makefile migliorato, distribuire in produzione o in staging diventa semplice come eseguire make deploy-production o make deploy-staging.

Versione migliorata del Makefile

Di seguito è riportato un Makefile migliorato che supporta più regole:

  • make dev (o semplicemente make): Avvia l'applicazione in modalità sviluppo.
  • make deploy: Distribuisce l'applicazione sul remoto chiamato stackhero. Funziona bene quando hai una sola istanza Stackhero.
  • make deploy-production: Distribuisce l'applicazione sul remoto chiamato stackhero-production.
  • make deploy-staging: Distribuisce l'applicazione sul remoto chiamato stackhero-staging.

Questo Makefile è progettato per gestire situazioni in cui il codice non è cambiato evitando l'errore "Everything up-to-date".

Copia e incolla il seguente contenuto come tuo nuovo Makefile:

# Regola da eseguire di default quando si invoca "make" senza argomento
.DEFAULT_GOAL := dev


# Stackhero per Python eseguirà la regola "run" sulla tua istanza.
# Questo è il comando da eseguire sui tuoi ambienti di produzione e staging.
run:
  ENV=production gunicorn app:app \
    --error-logfile - \
    -b 0.0.0.0:8080


# Il comando da usare nell'ambiente di sviluppo
dev:
  python app.py


# Regola "deploy" per distribuire sull'istanza "stackhero".
# Adatto se hai solo un'istanza.
deploy:
  @$(MAKE) -s deploy-script DEPLOY_REMOTE=stackhero DEPLOY_BRANCH=main


# Le regole "deploy-*" distribuiscono su un'istanza chiamata "stackhero-*".
# Ad esempio, eseguire "make deploy-production" distribuisce su "stackhero-production",
# o "make deploy-staging" distribuisce su "stackhero-staging".
deploy-%:
  @$(MAKE) -s deploy-script DEPLOY_REMOTE=stackhero-$* DEPLOY_BRANCH=main


# Regola di deployment interna. Non modificarla.
deploy-script:
  @echo "Distribuzione del branch \"${DEPLOY_BRANCH}\" su \"${DEPLOY_REMOTE}\"..."
  @echo

  @if [ -n "$$(git status --porcelain)" ]; then \
    echo "Impossibile distribuire perché ci sono modifiche non commesse:"; \
    echo "\e[0m"; \
    git status -s; \
    echo ""; \
    echo "\e[0;31m"; \
    echo "Puoi usare questo comando per commettere le modifiche:"; \
    echo "git add -A . && git commit -m \"Il tuo messaggio\""; \
    echo "\e[0m"; \
    exit 1; \
  fi

  @git push --dry-run ${DEPLOY_REMOTE} ${DEPLOY_BRANCH} 2>&1 | grep -q -F "Everything up-to-date"; \
  EXIT_CODE=$$?; \
  if [ $$EXIT_CODE -eq 0 ]; then \
    echo -n "Niente di nuovo da distribuire... Forzare il deployment (questo creerà un nuovo commit)? (y/N) "; \
    read answer && \
    case $$answer in \
      y|Y|yes|YES) \
      git commit --allow-empty -m "Force update for deploy purpose to \"${DEPLOY_REMOTE}\"" ; \
      ;; \
    *) \
      echo "Niente da distribuire!"; \
      exit 1; \
      ;; \
    esac \
  fi

  git push ${DEPLOY_REMOTE} ${DEPLOY_BRANCH}

Gestione dei segreti (variabili d'ambiente)

A un certo punto, dovrai memorizzare segreti come token e password per database o servizi di terze parti. È importante memorizzarli in modo sicuro. Evita di incorporarli direttamente nel tuo repository o codice poiché ciò crea un rischio significativo per la sicurezza.

L'uso delle variabili d'ambiente offre due vantaggi chiave:

  1. I tuoi segreti non sono mai memorizzati nel tuo repository Git, riducendo il rischio di accesso non autorizzato.
  2. Puoi usare credenziali diverse per vari ambienti, come usare un database di produzione in produzione e un database di sviluppo durante lo sviluppo.

Configurazione delle variabili d'ambiente per lo sviluppo

In un ambiente di sviluppo, crea un file .env alla radice del tuo progetto. Questo file dovrebbe essere escluso da Git per assicurarsi che non venga mai commesso.

Per leggere automaticamente il file .env, puoi usare il modulo python-dotenv:

pip install python-dotenv
pip freeze > requirements.txt

Quindi, crea un file .env alla radice del tuo progetto e aggiungi le tue variabili:

ENV="development"
DATABASE_PASSWORD="secretPassword"
THIRD_API_PRIVATE_KEY="secretKey"
# ...

Infine, assicurati che il file .env sia escluso da Git aggiungendolo al tuo .gitignore:

echo ".env" >> .gitignore

Configurazione delle variabili d'ambiente per staging e produzione

Il file .env non è sufficientemente sicuro per gli ambienti di staging e produzione. Invece, Stackhero ti consente di memorizzare in modo sicuro le tue variabili d'ambiente direttamente nella configurazione del tuo servizio Python.

Puoi impostare queste variabili nel dashboard di Stackhero selezionando il tuo servizio Python e poi cliccando sul pulsante "Configura".

Variabili d'ambiente Python su StackheroVariabili d'ambiente Python su Stackhero

Accesso alle variabili d'ambiente in Python

Accedere alle variabili d'ambiente in Python è semplice. Basta usare os.environ.get() come mostrato di seguito:

import os

print(os.environ.get('ENV'))

Ad esempio, connettersi a un server Redis utilizzando una variabile d'ambiente può essere fatto così:

import os
import redis

r = redis.from_url(os.environ.get("REDIS_URL"))

In un ambiente di sviluppo, imposta REDIS_URL nel tuo file .env come segue:

REDIS_URL="redis://localhost:6379"

Per produzione e staging, definisci REDIS_URL sul dashboard di Stackhero sotto la configurazione del servizio Python:

REDIS_URL="rediss://default:<yourPassword>@<XXXXXX>.stackhero-network.com:6380"

Gestione dei pacchetti Python

È una buona pratica gestire i pacchetti Python utilizzando un file requirements.txt. Questo file elenca tutti i pacchetti necessari e le loro versioni per eseguire il tuo codice in modo affidabile.

Mantenere questo file aggiornato garantisce:

  1. Tutti i pacchetti richiesti sono installati.
  2. Vengono utilizzate solo versioni di pacchetti compatibili.

Quando distribuisci sulla tua istanza Stackhero, i pacchetti specificati in requirements.txt vengono installati automaticamente.

Per generare o aggiornare requirements.txt, esegui il seguente comando dopo aver installato nuovi pacchetti:

pip freeze > requirements.txt

Apertura delle porte UDP/TCP

La maggior parte delle applicazioni Python utilizza le porte HTTP 80 (HTTP) e 443 (HTTPS).

Se la tua applicazione deve aprire porte aggiuntive o utilizza altri protocolli (TCP o UDP), puoi regolare l'impostazione "Ports Redirections" nel tuo servizio Python sul dashboard di Stackhero.

Per ogni porta aggiuntiva, specifica la porta di ingresso (pubblica), la porta di destinazione (utilizzata dalla tua applicazione Python) e il protocollo (TCP o UDP).

Redirezioni delle porte nel dashboard di StackheroRedirezioni delle porte nel dashboard di Stackhero

Archiviazione file

Per archiviare file come foto utente o documenti, è generalmente meglio utilizzare una soluzione di archiviazione oggetti.

L'archiviazione oggetti ti consente di condividere file tra più servizi o istanze e separa il tuo storage dal tuo codice, seguendo le migliori pratiche.

Raccomandiamo MinIO, una soluzione veloce e potente compatibile con il protocollo Amazon S3.

Se preferisci l'archiviazione file locale, puoi utilizzare lo storage persistente fornito con la tua istanza Python situato in /persistent/storage/. Tuttavia, questo approccio non è raccomandato nella maggior parte dei casi.

ATTENZIONE: Non archiviare mai dati al di fuori della cartella /persistent/storage/!

Archiviare dati al di fuori di questa cartella può portare a perdita di dati quando la tua istanza viene riavviata, aggiornata o quando invii nuovo codice.

Apple/macOS: salvare la password della tua chiave privata SSH

Su macOS, può essere scomodo inserire la password della tua chiave privata SSH ogni volta che invii il tuo codice. Sebbene la sicurezza sia fondamentale, puoi salvare la tua password in modo sicuro utilizzando il Portachiavi di Apple piuttosto che rimuoverla dalla tua chiave.

Per memorizzare la password di una chiave chiamata id_ed25519, esegui:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Dopo questo, non ti verrà più chiesto di inserire la password della tua chiave, risparmiando tempo e fatica.

Se usi una chiave RSA invece, sostituisci id_ed25519 con id_rsa nel comando:

ssh-add --apple-use-keychain ~/.ssh/id_rsa

Other articles for Python