Από Git Repository σε Production: Οδηγός Deploy με Dockup

Η μεταφορά ενός Git repository σε production απαιτεί περισσότερα από τη σύνδεση ενός remote και το πάτημα του deploy. Η πλατφόρμα πρέπει να γνωρίζει το service target, το branch, τη μέθοδο build, την εντολή εκκίνησης, τη θύρα ακρόασης, το environment, το health gate και τη διαδικασία recovery. Το Dockup κάνει αυτές τις επιλογές σαφείς, υποστηρίζοντας τόσο automatic builds με Nixpacks όσο και Dockerfiles που ανήκουν στο repository.

Αυτός ο οδηγός ξεκινά από ένα repository που δεν έχει γίνει ποτέ deploy και καταλήγει σε ένα επαληθευμένο URL, deployment history, logs και μια δοκιμασμένη εντολή rollback.

Τι πρέπει να ελεγχθεί πριν από το πρώτο production deploy;

Βεβαιωθείτε ότι το repository μπορεί να γίνει deploy χωρίς μη τεκμηριωμένη local state. Ένα clean clone πρέπει να περιέχει όλα όσα χρειάζονται για την εγκατάσταση των dependencies και την εκκίνηση της εφαρμογής, εκτός από τα secrets.

Χρησιμοποιήστε αυτήν τη checklist:

Check	Αναμενόμενο αποτέλεσμα
Default branch	Υπάρχει το production branch που προορίζεται για χρήση
Dependency lockfile	Έχει γίνει commit για reproducible installs
Start process	Κάνει bind στη ρυθμισμένη θύρα και στο 0.0.0.0
Health route	Επιστρέφει επιτυχία χωρίς εξωτερικές παρενέργειες
Database migrations	Διαθέτουν σαφές και ασφαλές execution plan
Secrets	Αποθηκεύονται εκτός Git
Persistent files	Χρησιμοποιούν volume και όχι το filesystem του container
Rollback	Το προηγούμενο deployment μπορεί να εκτελεστεί ξανά

Εγκαταστήστε το CLI και κάντε authenticate:

npm install -g dockup-cli
export DOCKUP_TOKEN="<TOKEN>"
dockup whoami --json

Εμφανίστε τα υπάρχοντα services πριν δημιουργήσετε οτιδήποτε:

dockup services --json

Έτσι αποφεύγετε τη δημιουργία duplicate resources και επιβεβαιώνετε το ακριβές workspace και το target convention.

Πώς υποστηρίζει το Dockup create το Git deployment;

Η συνηθισμένη εντολή για το πρώτο deploy δημιουργεί το service, κάνει deploy, περιμένει το αποτέλεσμα και συνδέει τον τρέχοντα κατάλογο:

dockup create api \
  --repo https://github.com/acme/api \
  --project production \
  --branch main \
  --deploy \
  --wait \
  --link \
  --json

Το target που προκύπτει είναι production/api. Το link .dockup επιτρέπει στις επόμενες εντολές να εντοπίζουν αυτό το service όταν εκτελούνται μέσα από το repository, όμως η τεκμηρίωση production θα πρέπει και πάλι να καταγράφει το πλήρες target.

Μετά από μια διακοπείσα προσπάθεια provisioning, εμφανίστε τα services και ελέγξτε το ακριβές target πριν εκτελέσετε ξανά τη δημιουργία:

dockup services --json

Αν το production/api υπάρχει ήδη, συνεχίστε διαβάζοντας το status και το deployment history του. Έτσι αποφεύγετε να μετατρέψετε ένα αβέβαιο αποτέλεσμα δικτύου σε duplicate service. Κρατήστε τα credentials πρόσβασης στο repository εκτός source control και output εντολών.

Πώς επιλέγει το Dockup μεταξύ Nixpacks και Dockerfile;

Αν το repository περιέχει Dockerfile, το Dockup το χρησιμοποιεί. Διαφορετικά, το Nixpacks εντοπίζει την εφαρμογή και πραγματοποιεί αυτόματα το build. Αυτή η σειρά καθιστά τον explicit container definition του repository authoritative.

Το Nixpacks είναι καλή πρώτη επιλογή όταν η εφαρμογή ακολουθεί τις συνηθισμένες συμβάσεις του ecosystem και δεν χρειάζεται customization σε επίπεδο operating system. Το Dockerfile είναι χρήσιμο όταν χρειάζεστε συγκεκριμένο base image, system packages, multi-stage build, custom runtime user ή ακριβή όρια αντιγραφής.

Δεν χρειάζεται να προσθέσετε ένα κενό Dockerfile απλώς για να «δείχνει έτοιμο για production». Ένα λανθασμένο Dockerfile μπορεί να είναι λιγότερο reproducible από ένα συμβατικό automatic build. Χρησιμοποιήστε τη διαδικασία απόφασης στο Nixpacks vs Dockerfile.

Ελέγξτε το service μετά τη δημιουργία:

dockup info production/api --json

Η απόκριση περιλαμβάνει το repository URL, το branch, τον τύπο deployment, τη θύρα, τις ρυθμίσεις build και start, τα environment keys, τα custom domains και τα δεδομένα του τελευταίου deployment.

Αν οι εντολές που εντοπίστηκαν χρειάζονται override, χρησιμοποιήστε τις τεκμηριωμένες ρυθμίσεις:

dockup set production/api \
  --build "npm ci && npm run build" \
  --start "npm start" \
  --port 3000 \
  --json

Οι ρυθμίσεις εφαρμόζονται στο επόμενο deployment.

Πώς ρυθμίζετε το production environment και το health;

Προσθέστε τις συνηθισμένες τιμές και τα secrets ξεχωριστά:

dockup env set NODE_ENV=production \
  -s production/api \
  --json

dockup env set DATABASE_URL="$DATABASE_URL" \
  --secret \
  -s production/api \
  --json

Οι τιμές των secrets εμφανίζονται masked κατά την προβολή του environment. Μπορούν να οριστούν ή να αντικατασταθούν, όμως η αποθηκευμένη τιμή δεν επιστρέφεται.

Οι αλλαγές στο environment απαιτούν redeploy, επειδή η running process δεν μπορεί να λάβει αναδρομικά ένα νέο environment. Ο πλήρης κύκλος ζωής εξηγείται στο environment variables and secrets.

Ρυθμίστε ένα health gate που να αντιπροσωπεύει την ετοιμότητα:

dockup health production/api \
  --path /healthz \
  --interval 5 \
  --timeout 3 \
  --retries 5 \
  --json

Το Dockup χρησιμοποιεί zero-downtime blue-green flow και στέλνει traffic στο νέο deployment μόνο αφού ολοκληρωθεί επιτυχώς ο έλεγχος readiness. Όταν δεν έχει ρυθμιστεί HTTP path, το gate μπορεί να βασιστεί στο TCP port readiness.

Ένα health route θα πρέπει να επιβεβαιώνει ότι η application process είναι έτοιμη να εξυπηρετήσει requests. Αποφύγετε να εκτελεί destructive checks ή ακριβά full-system tests. Οι deep dependency checks μπορούν να δημιουργήσουν false outages όταν ένα προαιρετικό service παρουσιάζει υποβάθμιση.

Πώς κάνετε deploy, παρακολουθείτε και επαληθεύετε το production;

Ενεργοποιήστε το release και περιμένετε μέχρι να φτάσει σε terminal state:

dockup deploy production/api --wait --json

Το default timeout είναι 900 δευτερόλεπτα. Η έξοδος 0 σημαίνει επιτυχία. Τα deploy_failed και deploy_timeout είναι non-zero results, επομένως τα shell scripts και τα CI systems σταματούν σωστά.

Για να παρακολουθήσετε το build ως NDJSON:

dockup logs production/api --build -f --json

Το stream ολοκληρώνεται με επιτυχία ή αποτυχία. Αν το build ολοκληρωθεί επιτυχώς αλλά το container κάνει crash, ελέγξτε τα runtime logs:

dockup logs production/api --json

Μετά από ένα επιτυχημένο release, επαληθεύστε την κατάσταση της πλατφόρμας και τη δημόσια συμπεριφορά:

dockup status production/api --json
dockup uptime production/api --hours 24 --json
dockup security production/api --json

Τα uptime probes εκτελούνται κάθε λεπτό και αναφέρουν τον μέσο χρόνο απόκρισης και τον χρόνο απόκρισης p95. Το security scanning ελέγχει image CVEs και configuration. Προσθέστε ένα application-specific smoke test για το πραγματικό business endpoint· το platform readiness είναι απαραίτητο, αλλά όχι επαρκές.

Η αναλυτική μέθοδος για τα logs είναι διαθέσιμη στο build and runtime log debugging.

Πώς πρέπει να εισαχθούν τα automatic deploys και τα previews;

Κάντε το πρώτο production release αρκετά χειροκίνητα ώστε να παρατηρήσετε κάθε boundary. Όταν επιβεβαιωθούν το build, το health gate και η διαδικασία rollback, ενεργοποιήστε το deployment on push:

dockup auto-deploy production/api --on --json

Το automatic deployment θα πρέπει να ακολουθεί protected branch και πολιτική code review. Ένα push αποτελεί production trigger, επομένως τα repository permissions γίνονται infrastructure permissions.

Τα pull request και branch previews παρέχουν isolated URLs και environments:

dockup pr-preview production/api --on --json
dockup preview branch feature/login production/api --json

Σε ένα project με private networking, τα previews συνδέονται στο project network. Μπορούν να επικοινωνήσουν με την ίδια production database στο <slug>.internal, όμως το Dockup δημιουργεί αυτόματα έναν read-only database user για το preview. Το preview μπορεί να εξετάζει production-shaped data χωρίς να γράφει σε αυτά.

Αυτό δεν εξαλείφει τις υποχρεώσεις privacy. Η πρόσβαση στα previews θα πρέπει και πάλι να είναι περιορισμένη, audited και να χρησιμοποιείται μόνο όπου επιτρέπεται η ανάγνωση production data.

Πώς κάνετε rollback ενός αποτυχημένου deployment;

Διατηρήστε τα στοιχεία πριν ξεκινήσετε το recovery. Διαβάστε τα build logs για build failure και τα runtime logs για crash. Στη συνέχεια, εμφανίστε το deployment history:

dockup deployments production/api -n 20 --json

Επιλέξτε ένα deployment ID με γνωστό status και timestamp και, στη συνέχεια, εκτελέστε το ξανά:

dockup rollback <deploymentId> production/api --json

Το rollback θα πρέπει να αποτελεί explicit incident action. Καταγράψτε το ID του failed deployment, το recovery ID που επιλέχθηκε, την αιτία και τη διορθωτική ενέργεια. Αν ένα database migration δεν είναι backward compatible, το application rollback από μόνο του μπορεί να μην αποκαταστήσει τη συμβατότητα· ο σχεδιασμός των migrations πρέπει να αποτελεί μέρος του release plan.

Ο οδηγός για το zero-downtime deployment εξηγεί το traffic cutover, ενώ το Dockup CLI reference τεκμηριώνει όλα τα command flags.

Record ολοκλήρωσης του πρώτου deploy

Στο τέλος της ροής Git repository σε production, καταγράψτε:

• Το ακριβές target project/service.
• Το repository και το production branch.
• Τη μέθοδο build: Nixpacks ή Dockerfile.
• Τις εντολές build και start, όταν έχουν γίνει override.
• Τη θύρα ακρόασης και το health path.
• Το deployment ID και το terminal status.
• Το production URL και το πλάνο για το custom domain.
• Την επαλήθευση uptime και security.
• Το rollback deployment ID ή τον κανόνα επιλογής.

Αυτό το record μετατρέπει το δεύτερο deployment σε routine operation αντί για μια ακόμη διαδικασία discovery.

Διαχωρίστε το application state από το container image

Το writable filesystem μέσα σε ένα service container θα πρέπει να θεωρείται replaceable. Ένα νέο deployment δημιουργεί νέα έκδοση και ένα rollback εκτελεί ξανά ένα παλαιότερο image· τα αρχεία που γράφτηκαν μόνο μέσα στο παλιό container δεν αποτελούν durable data strategy.

Χρησιμοποιήστε managed databases για relational, document ή cache state και συνδέστε ένα volume για αρχεία που πρέπει να παραμένουν μετά τα deployments. Επιβεβαιώστε τα mount paths πριν από το πρώτο production release. Ένας containerized upload directory που δεν έγινε ποτέ mount μπορεί να φαίνεται υγιής μέχρι το επόμενο deploy, όταν το data διαγραφεί.

Δείτε τα persistent volumes and snapshots πριν μεταφέρετε user-generated files. Για database state, χρησιμοποιήστε το database-specific backup system αντί να θεωρείτε ένα hot volume snapshot transaction-consistent backup.

Εκτιμήστε τον πρώτο μήνα χωρίς να επινοήσετε ένα σταθερό instance bill

Το Dockup μετρά την κατανάλωση CPU, RAM και disk ανά λεπτό και αφαιρεί τη χρήση από το plan balance. Το Free plan περιλαμβάνει starting credit $10 και έως τρία deployments· το προτεινόμενο Pro plan κοστίζει $20 τον μήνα και περιλαμβάνει usage credit $20.

Αφού το service δεχτεί πραγματικό traffic, ελέγξτε την κατανάλωση CPU, RAM και disk στο app.dockup.ai. Χρησιμοποιήστε την παρατηρούμενη κατανάλωση ανά λεπτό —όχι ένα guessed maximum— για να αποφασίσετε αν χρειάζεται προσαρμογή το service, η database ή το persistent disk.

Επαληθεύστε ένα καθαρό δεύτερο deployment

Μετά το πρώτο release, κάντε μια ακίνδυνη αλλαγή που έχει περάσει review και κάντε ξανά deploy. Έτσι επιβεβαιώνετε ότι το repository link, οι παραδοχές για το build cache, το health gate, το environment και το history λειτουργούν ως ongoing process και όχι ως επιτυχία provisioning που συνέβη μόνο μία φορά.

Διατηρήστε το target explicit

Καταγράψτε το τελικό string project/service.

Διατηρήστε το release URL

Καταγράψτε το production URL δίπλα στο deployment ID.

Επιβεβαιώστε το επόμενο trigger

Καταγράψτε αν τα μελλοντικά releases θα είναι manual ή θα χρησιμοποιούν το προαιρετικό deploy-on-push. Έτσι παραμένουν ευθυγραμμισμένα τα repository permissions, το branch protection και οι production expectations μετά το πρώτο deployment.

Ξεκινήστε με ένα deployment που μπορεί να επαληθευτεί

Επιλέξτε ένα μικρό repository με σαφή start command και health route και, μετά το πρώτο επιτυχημένο release, τεκμηριώστε το ακριβές target και το rollback ID.

Ξεκινήστε δωρεάν στο app.dockup.ai. Το Free plan κοστίζει $0 τον μήνα, περιλαμβάνει starting credit $10 και υποστηρίζει ένα workspace, τρεις databases και τρία deployments.

FAQ

Μπορεί το Dockup να κάνει deploy ένα repository χωρίς Dockerfile;

Ναι. Όταν δεν υπάρχει Dockerfile, το Dockup χρησιμοποιεί το Nixpacks για να εντοπίσει και να κάνει αυτόματα build της εφαρμογής.

Τι κάνει το dockup create --link;

Γράφει ένα link .dockup στον τρέχοντα κατάλογο, ώστε οι επόμενες εντολές να μπορούν να εντοπίζουν το συνδεδεμένο project/service target.

Γιατί πρέπει το πρώτο deploy να χρησιμοποιεί το --wait;

Διατηρεί την εντολή συνδεδεμένη μέχρι το deployment να φτάσει σε επιτυχία, αποτυχία ή timeout και επιστρέφει exit code που αντιπροσωπεύει με ακρίβεια το terminal result.

Εφαρμόζονται αμέσως οι αλλαγές στις environment variables;

Όχι. Εφαρμόζονται σε νέο container στο επόμενο deployment, επομένως κάντε redeploy το service μετά την αλλαγή του environment configuration.

Πώς κάνει rollback μιας εφαρμογής το Dockup;

Εμφανίστε το deployment history, εντοπίστε ένα γνωστό προηγούμενο deployment ID και χρησιμοποιήστε το dockup rollback με αυτό το ID και το ακριβές service target.