Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Όλα ξεκίνησαν όταν ο επικεφαλής της ομάδας μιας από τις ομάδες ανάπτυξης μας ζήτησε να δοκιμάσουμε τη νέα τους εφαρμογή, η οποία είχε τοποθετηθεί σε κοντέινερ την προηγούμενη μέρα. Το δημοσίευσα. Μετά από περίπου 20 λεπτά, λήφθηκε αίτημα ενημέρωσης της εφαρμογής, γιατί εκεί είχε προστεθεί κάτι πολύ απαραίτητο. ανανέωσα. Μετά από άλλες δύο ώρες... λοιπόν, μπορείτε να μαντέψετε τι άρχισε να συμβαίνει μετά...

Πρέπει να ομολογήσω, είμαι πολύ τεμπέλης (δεν το παραδέχτηκα νωρίτερα; Όχι;), και δεδομένου του γεγονότος ότι οι επικεφαλής των ομάδων έχουν πρόσβαση στο Jenkins, στο οποίο έχουμε όλα τα CI/CD, σκέφτηκα: αφήστε τον να αναπτυχθεί ως όσο θέλει! Θυμήθηκα ένα αστείο: δώσε σε έναν άνθρωπο ένα ψάρι και θα φάει για μια μέρα. καλέστε ένα άτομο Fed και θα είναι Fed όλη του τη ζωή. Και πήγα παίζουν κόλπα στη δουλειά, το οποίο θα είναι σε θέση να αναπτύξει ένα κοντέινερ που περιέχει την εφαρμογή οποιασδήποτε επιτυχώς ενσωματωμένης έκδοσης στο Kuber και να μεταφέρει οποιεσδήποτε τιμές σε αυτό ENV (ο παππούς μου, φιλόλογος, δάσκαλος αγγλικών στο παρελθόν, στριφογύριζε τώρα το δάχτυλό του στον κρόταφο και με κοιτούσε πολύ εκφραστικά αφού διάβαζε αυτή τη φράση).

Έτσι, σε αυτό το σημείωμα θα σας πω πώς έμαθα:

  1. Ενημερώστε δυναμικά τις εργασίες στο Jenkins από την ίδια την εργασία ή από άλλες εργασίες.
  2. Συνδεθείτε στην κονσόλα cloud (κέλυφος Cloud) από έναν κόμβο με εγκατεστημένο τον πράκτορα Jenkins.
  3. Ανάπτυξη φόρτου εργασίας στο Google Kubernetes Engine.


Στην πραγματικότητα, είμαι, φυσικά, κάπως ανειλικρινής. Υποτίθεται ότι διαθέτετε τουλάχιστον μέρος της υποδομής στο Google cloud και, επομένως, είστε ο χρήστης του και, φυσικά, έχετε λογαριασμό GCP. Αλλά δεν πρόκειται για αυτό το σημείωμα.

Αυτό είναι το επόμενο φύλλο απάτης μου. Θέλω να γράψω τέτοιες σημειώσεις μόνο σε μία περίπτωση: αντιμετώπισα ένα πρόβλημα, αρχικά δεν ήξερα πώς να το λύσω, η λύση δεν ήταν έτοιμη στο google, οπότε την έψαξα στο google σε μέρη και τελικά έλυσα το πρόβλημα. Και έτσι ώστε στο μέλλον, όταν ξεχάσω πώς το έκανα, δεν χρειάζεται να ψάξω ξανά στο google τα πάντα κομμάτι-κομμάτι και να τα συντάξω μαζί, γράφω στον εαυτό μου τέτοια cheat sheets.

Αποποίηση ευθυνών: 1. Το σημείωμα γράφτηκε «για τον εαυτό μου», για τον ρόλο βέλτιστων πρακτικών δεν ισχύει. Είμαι στην ευχάριστη θέση να διαβάσω τις επιλογές "θα ήταν καλύτερα να το κάνω με αυτόν τον τρόπο" στα σχόλια.
2. Εάν το εφαρμοσμένο μέρος της νότας θεωρείται αλάτι, τότε, όπως όλες οι προηγούμενες νότες μου, αυτή είναι ένα ασθενές διάλυμα αλατιού.

Δυναμική ενημέρωση ρυθμίσεων εργασίας στο Jenkins

Προβλέπω την ερώτησή σας: τι σχέση έχει η δυναμική ενημέρωση εργασίας; Εισαγάγετε την τιμή της παραμέτρου συμβολοσειράς χειροκίνητα και ξεκινήστε!

Απαντώ: Είμαι πραγματικά τεμπέλης, δεν μου αρέσει όταν παραπονιούνται: Μίσα, η ανάπτυξη καταρρέει, όλα έχουν φύγει! Αρχίζετε να ψάχνετε και υπάρχει ένα τυπογραφικό λάθος στην τιμή κάποιας παραμέτρου εκκίνησης εργασιών. Ως εκ τούτου, προτιμώ να κάνω τα πάντα όσο το δυνατόν πιο αποτελεσματικά. Εάν είναι δυνατό να αποτραπεί ο χρήστης από την απευθείας εισαγωγή δεδομένων δίνοντας αντί αυτού μια λίστα τιμών για να επιλέξει, τότε οργανώνω την επιλογή.

Το σχέδιο είναι το εξής: δημιουργούμε μια εργασία στο Jenkins, στην οποία, πριν από την εκκίνηση, θα μπορούσαμε να επιλέξουμε μια έκδοση από τη λίστα, να καθορίσουμε τιμές για τις παραμέτρους που μεταβιβάζονται στο κοντέινερ μέσω ENV, στη συνέχεια συλλέγει το κοντέινερ και το σπρώχνει στο Μητρώο κοντέινερ. Στη συνέχεια, από εκεί το δοχείο εκτοξεύεται σε cuber as φόρτο εργασίας με τις παραμέτρους που καθορίζονται στην εργασία.

Δεν θα εξετάσουμε τη διαδικασία δημιουργίας και δημιουργίας εργασίας στο Jenkins, αυτό είναι εκτός θέματος. Θα υποθέσουμε ότι η εργασία είναι έτοιμη. Για να εφαρμόσουμε μια ενημερωμένη λίστα με εκδόσεις, χρειαζόμαστε δύο πράγματα: μια υπάρχουσα λίστα πηγών με εκ των προτέρων έγκυρους αριθμούς εκδόσεων και μια μεταβλητή όπως Παράμετρος επιλογής στην εργασία. Στο παράδειγμά μας, ας ονομαστεί η μεταβλητή BUILD_VERSION, δεν θα σταθούμε αναλυτικά σε αυτό. Αλλά ας ρίξουμε μια πιο προσεκτική ματιά στη λίστα πηγών.

Δεν υπάρχουν τόσες πολλές επιλογές. Δύο πράγματα μου ήρθαν αμέσως στο μυαλό:

  • Χρησιμοποιήστε το API απομακρυσμένης πρόσβασης που προσφέρει η Jenkins στους χρήστες της.
  • Ζητήστε τα περιεχόμενα του φακέλου απομακρυσμένου αποθετηρίου (στην περίπτωσή μας αυτό είναι το JFrog Artifactory, το οποίο δεν είναι σημαντικό).

Jenkins Remote Access API

Σύμφωνα με την καθιερωμένη εξαιρετική παράδοση, θα προτιμούσα να αποφύγω τις μακροσκελείς εξηγήσεις.
Θα επιτρέψω στον εαυτό μου μόνο μια ελεύθερη μετάφραση ενός κομματιού της πρώτης παραγράφου πρώτη σελίδα της τεκμηρίωσης API:

Το Jenkins παρέχει ένα API για απομακρυσμένη αναγνώσιμη από μηχανή πρόσβαση στη λειτουργικότητά του. <…> Η απομακρυσμένη πρόσβαση προσφέρεται σε στυλ REST. Αυτό σημαίνει ότι δεν υπάρχει ένα μόνο σημείο εισόδου σε όλες τις λειτουργίες, αλλά αντίθετα μια διεύθυνση URL όπως ".../api/", Οπου "..." σημαίνει το αντικείμενο στο οποίο εφαρμόζονται οι δυνατότητες API.

Με άλλα λόγια, εάν η εργασία ανάπτυξης για την οποία μιλάμε είναι διαθέσιμη στο http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build, τότε οι σφυρίχτρες API για αυτήν την εργασία είναι διαθέσιμες στη διεύθυνση http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/

Στη συνέχεια, έχουμε την επιλογή σε ποια μορφή θα λάβουμε την έξοδο. Ας εστιάσουμε στην XML, αφού το API επιτρέπει μόνο φιλτράρισμα σε αυτήν την περίπτωση.

Ας προσπαθήσουμε απλώς να λάβουμε μια λίστα με όλες τις τρέχουσες εργασίες. Μας ενδιαφέρει μόνο το όνομα της συνέλευσης (displayName) και το αποτέλεσμά του (αποτέλεσμα):

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]

Αποδείχθηκε;

Τώρα ας φιλτράρουμε μόνο εκείνες τις διαδρομές που καταλήγουν στο αποτέλεσμα ΕΠΙΤΥΧΙΑ. Ας χρησιμοποιήσουμε το επιχείρημα &αποκλείω και ως παράμετρο θα της περάσουμε τη διαδρομή σε μια τιμή που δεν ισούται με ΕΠΙΤΥΧΙΑ. Ναι ναι. Ένα διπλό αρνητικό είναι μια δήλωση. Αποκλείουμε όλα όσα δεν μας ενδιαφέρουν:

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!='SUCCESS']

Στιγμιότυπο οθόνης της λίστας των επιτυχημένων
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Λοιπόν, για πλάκα, ας βεβαιωθούμε ότι το φίλτρο δεν μας εξαπάτησε (τα φίλτρα δεν λένε ποτέ ψέματα!) και ας εμφανίσουμε μια λίστα με "αποτυχημένα":

http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result='SUCCESS']

Στιγμιότυπο οθόνης της λίστας των μη επιτυχημένων
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Λίστα εκδόσεων από φάκελο σε απομακρυσμένο διακομιστή

Υπάρχει ένας δεύτερος τρόπος για να λάβετε μια λίστα εκδόσεων. Μου αρέσει περισσότερο από την πρόσβαση στο Jenkins API. Λοιπόν, επειδή εάν η εφαρμογή κατασκευάστηκε με επιτυχία, σημαίνει ότι συσκευάστηκε και τοποθετήθηκε στο αποθετήριο στον κατάλληλο φάκελο. Όπως, ένα αποθετήριο είναι η προεπιλεγμένη αποθήκευση των λειτουργικών εκδόσεων εφαρμογών. Αρέσει. Λοιπόν, ας τον ρωτήσουμε ποιες εκδόσεις είναι αποθηκευμένες. Θα κουλουριάσουμε, θα γραπώσουμε και θα ανοίξουμε τον απομακρυσμένο φάκελο. Αν κάποιος ενδιαφέρεται για το oneliner, τότε είναι κάτω από το spoiler.

Εντολή μίας γραμμής
Λάβετε υπόψη δύο πράγματα: Περνάω τα στοιχεία σύνδεσης στην κεφαλίδα και δεν χρειάζομαι όλες τις εκδόσεις από το φάκελο και επιλέγω μόνο εκείνες που δημιουργήθηκαν μέσα σε ένα μήνα. Επεξεργαστείτε την εντολή ώστε να ταιριάζει στις πραγματικότητες και τις ανάγκες σας:

curl -H "X-JFrog-Art-Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

Ρύθμιση εργασιών και αρχείου διαμόρφωσης εργασιών στο Jenkins

Καταλάβαμε την πηγή της λίστας των εκδόσεων. Ας ενσωματώσουμε τώρα τη λίστα που προκύπτει στην εργασία. Για μένα, η προφανής λύση ήταν να προσθέσω ένα βήμα στην εργασία δημιουργίας εφαρμογής. Το βήμα που θα εκτελούνταν αν το αποτέλεσμα ήταν «επιτυχία».

Ανοίξτε τις ρυθμίσεις εργασιών συναρμολόγησης και μετακινηθείτε προς τα κάτω. Κάντε κλικ στα κουμπιά: Προσθήκη βήματος κατασκευής -> Βήμα υπό όρους (μονό). Στις ρυθμίσεις βημάτων, επιλέξτε τη συνθήκη Τρέχουσα κατάσταση κατασκευής, ορίστε την τιμή ΕΠΙΤΥΧΙΑ, η ενέργεια που πρέπει να εκτελεστεί εάν είναι επιτυχής Εκτέλεση εντολής κελύφους.

Και τώρα το διασκεδαστικό κομμάτι. Το Jenkins αποθηκεύει τις διαμορφώσεις εργασιών σε αρχεία. Σε μορφή XML. Στην πορεία http://путь-до-задания/config.xml Αντίστοιχα, μπορείτε να κάνετε λήψη του αρχείου διαμόρφωσης, να το επεξεργαστείτε όπως χρειάζεται και να το επαναφέρετε εκεί που το πήρατε.

Θυμηθείτε, συμφωνήσαμε παραπάνω ότι θα δημιουργήσουμε μια παράμετρο για τη λίστα των εκδόσεων BUILD_VERSION?

Ας κατεβάσουμε το αρχείο ρυθμίσεων και ας ρίξουμε μια ματιά στο εσωτερικό του. Απλά για να βεβαιωθείτε ότι η παράμετρος είναι στη θέση της και του επιθυμητού τύπου.

Στιγμιότυπο κάτω από το σπόιλερ.

Το τμήμα config.xml θα πρέπει να έχει την ίδια εμφάνιση. Εκτός από το ότι λείπουν ακόμη τα περιεχόμενα του στοιχείου επιλογών
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Είσαι σίγουρος? Αυτό ήταν όλο, ας γράψουμε ένα σενάριο που θα εκτελεστεί εάν η κατασκευή είναι επιτυχής.
Το σενάριο θα λάβει μια λίστα εκδόσεων, θα πραγματοποιήσει λήψη του αρχείου διαμόρφωσης, θα γράψει τη λίστα των εκδόσεων σε αυτό στη θέση που χρειαζόμαστε και, στη συνέχεια, θα το επαναφέρει. Ναί. Σωστά. Γράψτε μια λίστα εκδόσεων σε XML στο μέρος όπου υπάρχει ήδη μια λίστα εκδόσεων (θα είναι στο μέλλον, μετά την πρώτη εκκίνηση του σεναρίου). Ξέρω ότι υπάρχουν ακόμα ένθερμοι οπαδοί των κανονικών εκφράσεων στον κόσμο. Δεν ανήκω σε αυτούς. Εγκαταστήστε xmlstarler στο μηχάνημα όπου θα γίνει επεξεργασία των παραμέτρων. Μου φαίνεται ότι αυτό δεν είναι τόσο μεγάλο τίμημα για να αποφύγετε την επεξεργασία XML χρησιμοποιώντας sed.

Κάτω από το spoiler παρουσιάζω ολόκληρο τον κώδικα που εκτελεί την παραπάνω ακολουθία.

Γράψτε μια λίστα εκδόσεων από έναν φάκελο στον απομακρυσμένο διακομιστή στη διαμόρφωση

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Читаем в массив список версий из репозитория
readarray -t vers < <( curl -H "X-JFrog-Art-Api:Api:VeryLongAPIKey" -s http://arts.myre.po/artifactory/awesomeapp/ | sed 's/a href=//' | grep "$(date +%b)-$(date +%Y)|$(date +%b --date='-1 month')-$(date +%Y)" | awk '{print $1}' | grep -oP '>K[^/]+' )

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

Εάν προτιμάτε την επιλογή να λαμβάνετε εκδόσεις από τον Jenkins και είστε τόσο τεμπέλης όσο εγώ, τότε κάτω από το spoiler είναι ο ίδιος κωδικός, αλλά μια λίστα από τον Jenkins:

Γράψτε μια λίστα με εκδόσεις από το Jenkins στη διαμόρφωση
Απλώς έχετε αυτό κατά νου: το όνομα της συναρμολόγησης μου αποτελείται από έναν αριθμό σειράς και έναν αριθμό έκδοσης, που χωρίζονται με άνω και κάτω τελεία. Αντίστοιχα, το awk κόβει το περιττό μέρος. Για τον εαυτό σας, αλλάξτε αυτή τη γραμμή για να ταιριάζει στις ανάγκες σας.

#!/bin/bash
############## Скачиваем конфиг
curl -X GET -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml -o appConfig.xml

############## Удаляем и заново создаем xml-элемент для списка версий
xmlstarlet ed --inplace -d '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' appConfig.xml

xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]' --type elem -n a appConfig.xml

xmlstarlet ed --inplace --insert '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a' --type attr -n class -v string-array appConfig.xml

############## Пишем в файл список версий из Jenkins
curl -g -X GET -u username:apiKey 'http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_build/api/xml?tree=allBuilds[displayName,result]&exclude=freeStyleProject/allBuild[result!=%22SUCCESS%22]&pretty=true' -o builds.xml

############## Читаем в массив список версий из XML
readarray vers < <(xmlstarlet sel -t -v "freeStyleProject/allBuild/displayName" builds.xml | awk -F":" '{print $2}')

############## Пишем массив элемент за элементом в конфиг
printf '%sn' "${vers[@]}" | sort -r | 
                while IFS= read -r line
                do
                    xmlstarlet ed --inplace --subnode '/project/properties/hudson.model.ParametersDefinitionProperty/parameterDefinitions/hudson.model.ChoiceParameterDefinition[name="BUILD_VERSION"]/choices[@class="java.util.Arrays$ArrayList"]/a[@class="string-array"]' --type elem -n string -v "$line" appConfig.xml
                done

############## Кладем конфиг взад
curl -X POST -u username:apiKey http://jenkins.mybuild.er/view/AweSomeApp/job/AweSomeApp_k8s/config.xml --data-binary @appConfig.xml

############## Приводим рабочее место в порядок
rm -f appConfig.xml

Θεωρητικά, εάν έχετε δοκιμάσει τον κώδικα που γράφτηκε με βάση τα παραπάνω παραδείγματα, τότε στην εργασία ανάπτυξης θα πρέπει να έχετε ήδη μια αναπτυσσόμενη λίστα με εκδόσεις. Είναι όπως στο στιγμιότυπο κάτω από το σπόιλερ.

Σωστά συμπληρωμένη λίστα εκδόσεων
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Εάν όλα δούλεψαν, τότε κάντε αντιγραφή-επικόλληση του σεναρίου Εκτέλεση εντολής κελύφους και αποθηκεύστε τις αλλαγές.

Σύνδεση στο κέλυφος Cloud

Έχουμε συλλέκτες σε δοχεία. Χρησιμοποιούμε το Ansible ως εργαλείο παράδοσης εφαρμογών και διαχειριστή διαμόρφωσης. Αντίστοιχα, όταν πρόκειται για την κατασκευή κοντέινερ, έρχονται στο μυαλό τρεις επιλογές: εγκατάσταση Docker στο Docker, εγκατάσταση Docker σε μηχάνημα που λειτουργεί με Ansible ή δημιουργία κοντέινερ σε μια κονσόλα cloud. Συμφωνήσαμε να παραμείνουμε σιωπηλοί σχετικά με τις προσθήκες για το Jenkins σε αυτό το άρθρο. Θυμάμαι?

Αποφάσισα: καλά, αφού τα κοντέινερ "out of the box" μπορούν να συλλεχθούν στην κονσόλα cloud, τότε γιατί να ασχοληθώ; Διατηρήστε το καθαρό, σωστά; Θέλω να συλλέξω κοντέινερ Jenkins στην κονσόλα cloud και μετά να τα εκτοξεύσω στο cuber από εκεί. Επιπλέον, η Google διαθέτει πολύ πλούσια κανάλια στην υποδομή της, τα οποία θα έχουν ευεργετική επίδραση στην ταχύτητα ανάπτυξης.

Για να συνδεθείτε στην κονσόλα cloud, χρειάζεστε δύο πράγματα: gcloud και δικαιώματα πρόσβασης σε Google Cloud API για την περίπτωση VM με την οποία θα γίνει αυτή η ίδια σύνδεση.

Για όσους σχεδιάζουν να συνδεθούν καθόλου από το Google cloud
Η Google επιτρέπει τη δυνατότητα απενεργοποίησης της διαδραστικής εξουσιοδότησης στις υπηρεσίες της. Αυτό θα σας επιτρέψει να συνδεθείτε στην κονσόλα ακόμα και από μια καφετιέρα, εάν λειτουργεί με *nix και έχει η ίδια κονσόλα.

Εάν χρειάζεται να καλύψω αυτό το θέμα λεπτομερέστερα στο πλαίσιο αυτής της σημείωσης, γράψτε στα σχόλια. Εάν έχουμε αρκετές ψήφους, θα γράψω μια ενημέρωση για αυτό το θέμα.

Ο ευκολότερος τρόπος παραχώρησης δικαιωμάτων είναι μέσω της διεπαφής ιστού.

  1. Διακόψτε την παρουσία VM από την οποία θα συνδεθείτε στη συνέχεια στην κονσόλα cloud.
  2. Ανοίξτε το Instance Details και κάντε κλικ τροποποιήσει.
  3. Στο κάτω μέρος της σελίδας, επιλέξτε το εύρος πρόσβασης παρουσίας Πλήρης πρόσβαση σε όλα τα Cloud API.

    Screenshot
    Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

  4. Αποθηκεύστε τις αλλαγές σας και ξεκινήστε την παρουσία.

Μόλις ολοκληρωθεί η φόρτωση του VM, συνδεθείτε σε αυτό μέσω SSH και βεβαιωθείτε ότι η σύνδεση πραγματοποιείται χωρίς σφάλμα. Χρησιμοποιήστε την εντολή:

gcloud alpha cloud-shell ssh

Μια επιτυχημένη σύνδεση μοιάζει κάπως έτσι
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Αποστολή στο ΓΚΕ

Δεδομένου ότι προσπαθούμε με κάθε δυνατό τρόπο να μεταβούμε πλήρως στο IaC (Infrastucture as a Code), τα αρχεία docker μας αποθηκεύονται στο Git. Αυτό είναι από τη μια πλευρά. Και η ανάπτυξη στο kubernetes περιγράφεται από ένα αρχείο yaml, το οποίο χρησιμοποιείται μόνο από αυτήν την εργασία, η οποία είναι επίσης σαν κώδικας. Αυτό είναι από την άλλη πλευρά. Σε γενικές γραμμές, εννοώ, το σχέδιο είναι το εξής:

  1. Παίρνουμε τις τιμές των μεταβλητών BUILD_VERSION και, προαιρετικά, τις τιμές των μεταβλητών που θα περάσουν ENV.
  2. Κατεβάστε το αρχείο docker από το Git.
  3. Δημιουργήστε yaml για ανάπτυξη.
  4. Ανεβάζουμε και τα δύο αυτά αρχεία μέσω scp στην κονσόλα cloud.
  5. Δημιουργούμε ένα κοντέινερ εκεί και το σπρώχνουμε στο μητρώο κοντέινερ
  6. Εφαρμόζουμε το αρχείο ανάπτυξης φορτίου στο cuber.

Ας γίνουμε πιο συγκεκριμένοι. Κάποτε αρχίσαμε να μιλάμε για ENV, τότε ας υποθέσουμε ότι πρέπει να περάσουμε τις τιμές δύο παραμέτρων: ΠΑΡΑΜ1 и ΠΑΡΑΜ2. Προσθέτουμε την εργασία τους για ανάπτυξη, πληκτρολογήστε - Παράμετρος συμβολοσειράς.

Screenshot
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Θα δημιουργήσουμε yaml με μια απλή ανακατεύθυνση ηχώ να αρχειοθετήσω. Υποτίθεται, φυσικά, ότι έχετε στο dockerfile σας ΠΑΡΑΜ1 и ΠΑΡΑΜ2ότι το όνομα φορτίου θα είναι φοβερή εφαρμογή, και το συναρμολογημένο δοχείο με την εφαρμογή της καθορισμένης έκδοσης βρίσκεται μέσα Μητρώο κοντέινερ στην πορεία gcr.io/awesomeapp/awesomeapp-$BUILD_VERSIONΌπου $BUILD_VERSION μόλις επιλέχθηκε από την αναπτυσσόμενη λίστα.

Καταχώριση ομάδας

touch deploy.yaml
echo "apiVersion: apps/v1" >> deploy.yaml
echo "kind: Deployment" >> deploy.yaml
echo "metadata:" >> deploy.yaml
echo "  name: awesomeapp" >> deploy.yaml
echo "spec:" >> deploy.yaml
echo "  replicas: 1" >> deploy.yaml
echo "  selector:" >> deploy.yaml
echo "    matchLabels:" >> deploy.yaml
echo "      run: awesomeapp" >> deploy.yaml
echo "  template:" >> deploy.yaml
echo "    metadata:" >> deploy.yaml
echo "      labels:" >> deploy.yaml
echo "        run: awesomeapp" >> deploy.yaml
echo "    spec:" >> deploy.yaml
echo "      containers:" >> deploy.yaml
echo "      - name: awesomeapp" >> deploy.yaml
echo "        image: gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION:latest" >> deploy.yaml
echo "        env:" >> deploy.yaml
echo "        - name: PARAM1" >> deploy.yaml
echo "          value: $PARAM1" >> deploy.yaml
echo "        - name: PARAM2" >> deploy.yaml
echo "          value: $PARAM2" >> deploy.yaml

Πράκτορας Jenkins μετά τη σύνδεση χρησιμοποιώντας gcloud alpha cloud-shell ssh Η διαδραστική λειτουργία δεν είναι διαθέσιμη, επομένως στέλνουμε εντολές στην κονσόλα cloud χρησιμοποιώντας την παράμετρο --εντολή.

Καθαρίζουμε τον αρχικό φάκελο στην κονσόλα cloud από το παλιό αρχείο docker:

gcloud alpha cloud-shell ssh --command="rm -f Dockerfile"

Τοποθετήστε το πρόσφατα κατεβασμένο αρχείο docker στον αρχικό φάκελο της κονσόλας cloud χρησιμοποιώντας το scp:

gcloud alpha cloud-shell scp localhost:./Dockerfile cloudshell:~

Συλλέγουμε, προσθέτουμε ετικέτα και προωθούμε το κοντέινερ στο μητρώο του κοντέινερ:

gcloud alpha cloud-shell ssh --command="docker build -t awesomeapp-$BUILD_VERSION ./ --build-arg BUILD_VERSION=$BUILD_VERSION --no-cache"
gcloud alpha cloud-shell ssh --command="docker tag awesomeapp-$BUILD_VERSION gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"
gcloud alpha cloud-shell ssh --command="docker push gcr.io/awesomeapp/awesomeapp-$BUILD_VERSION"

Κάνουμε το ίδιο με το αρχείο ανάπτυξης. Λάβετε υπόψη ότι οι παρακάτω εντολές χρησιμοποιούν εικονικά ονόματα του συμπλέγματος όπου πραγματοποιείται η ανάπτυξη (awsm-cluster) και όνομα έργου (φοβερό έργο), όπου βρίσκεται το σύμπλεγμα.

gcloud alpha cloud-shell ssh --command="rm -f deploy.yaml"
gcloud alpha cloud-shell scp localhost:./deploy.yaml cloudshell:~
gcloud alpha cloud-shell ssh --command="gcloud container clusters get-credentials awsm-cluster --zone us-central1-c --project awesome-project && 
kubectl apply -f deploy.yaml"

Εκτελούμε την εργασία, ανοίγουμε την έξοδο της κονσόλας και ελπίζουμε να δούμε την επιτυχή συναρμολόγηση του κοντέινερ.

Screenshot
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Και μετά η επιτυχής ανάπτυξη του συναρμολογημένου κοντέινερ

Screenshot
Δημιουργούμε μια εργασία ανάπτυξης στο GKE χωρίς πρόσθετα, SMS ή εγγραφή. Ας ρίξουμε μια ματιά κάτω από το σακάκι του Τζένκινς

Σκόπιμα αγνόησα τη ρύθμιση Είσοδος. Για έναν απλό λόγο: μόλις το ρυθμίσετε φόρτο εργασίας με ένα δεδομένο όνομα, θα παραμείνει λειτουργικό, ανεξάρτητα από το πόσες αναπτύξεις με αυτό το όνομα θα εκτελέσετε. Λοιπόν, γενικά, αυτό είναι λίγο έξω από το πεδίο της ιστορίας.

Αντί για συμπεράσματα

Όλα τα παραπάνω βήματα μάλλον δεν θα μπορούσαν να έχουν γίνει, αλλά απλώς εγκαταστάθηκε κάποιο πρόσθετο για το Jenkins, το muuulion τους. Αλλά για κάποιο λόγο δεν μου αρέσουν τα πρόσθετα. Λοιπόν, πιο συγκεκριμένα, σε αυτά καταφεύγω μόνο από απελπισία.

Και απλά μου αρέσει να αναλαμβάνω κάποιο νέο θέμα για μένα. Το παραπάνω κείμενο είναι επίσης ένας τρόπος να μοιραστώ τα ευρήματα που έκανα κατά την επίλυση του προβλήματος που περιγράφηκε στην αρχή. Μοιραστείτε το με εκείνους που, όπως αυτός, δεν είναι καθόλου τρομερός λύκος στο devops. Εάν τα ευρήματά μου βοηθήσουν τουλάχιστον κάποιον, θα είμαι ευχαριστημένος.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο