Δημιουργία ενός έργου Android σε ένα κοντέινερ Docker

Όταν αναπτύσσετε ένα έργο για την πλατφόρμα Android, ακόμα και το πιο μικρό, αργά ή γρήγορα θα πρέπει να αντιμετωπίσετε το περιβάλλον ανάπτυξης. Εκτός από το Android SDK, είναι απαραίτητο να έχετε την τελευταία έκδοση των Kotlin, Gradle, platform-tools, build-tools. Και αν στο μηχάνημα του προγραμματιστή όλες αυτές οι εξαρτήσεις επιλυθούν σε μεγαλύτερο βαθμό χρησιμοποιώντας το Android Studio IDE, τότε στον διακομιστή CI / CD, κάθε ενημέρωση μπορεί να μετατραπεί σε πονοκέφαλο. Και αν στην ανάπτυξη ιστού, το Docker έχει γίνει η τυπική λύση στο πρόβλημα του περιβάλλοντος, τότε γιατί να μην προσπαθήσετε να λύσετε ένα παρόμοιο πρόβλημα με αυτό στην ανάπτυξη Android ...

Για όσους δεν ξέρουν τι είναι το Docker - αν είναι αρκετά απλό, τότε αυτό είναι ένα εργαλείο για τη δημιουργία του λεγόμενου. «Containers» που περιέχουν τον ελάχιστο πυρήνα λειτουργικού συστήματος και το απαραίτητο σύνολο λογισμικού που μπορούμε να αναπτύξουμε όπου θέλουμε, διατηρώντας παράλληλα το περιβάλλον. Το τι ακριβώς θα υπάρχει στο κοντέινερ μας καθορίζεται στο Dockerfile, το οποίο στη συνέχεια συναρμολογείται σε μια εικόνα που μπορεί να εκκινηθεί οπουδήποτε και έχει ιδιότητες ανικανότητας.

Η διαδικασία εγκατάστασης και τα βασικά του Docker περιγράφονται όμορφα στο δικό του επίσημη ιστοσελίδα. Επομένως, κοιτάζοντας λίγο μπροστά, έχουμε ένα τέτοιο Dockerfile

# Т.к. основным инструментом для сборки Android-проектов является Gradle, 
# и по счастливому стечению обстоятельств есть официальный Docker-образ 
# мы решили за основу взять именно его с нужной нам версией Gradle
FROM gradle:5.4.1-jdk8

# Задаем переменные с локальной папкой для Android SDK и 
# версиями платформы и инструментария
ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=28 
    ANDROID_BUILD_TOOLS_VERSION=28.0.3

# Создаем папку, скачиваем туда SDK и распаковываем архив,
# который после сборки удаляем
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
# В следующих строчках мы создаем папку и текстовые файлы 
# с лицензиями. На оф. сайте Android написано что мы 
# можем копировать эти файлы с машин где вручную эти 
# лицензии подтвердили и что автоматически 
# их сгенерировать нельзя
    && mkdir "$ANDROID_HOME/licenses" || true 
    && echo "24333f8a63b6825ea9c5514f83c2829b004d1" > "$ANDROID_HOME/licenses/android-sdk-license" 
    && echo "84831b9409646a918e30573bab4c9c91346d8" > "$ANDROID_HOME/licenses/android-sdk-preview-license"    

# Запускаем обновление SDK и установку build-tools, platform-tools
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

Το αποθηκεύουμε στο φάκελο με το έργο μας στο Android και ξεκινάμε τη δημιουργία του κοντέινερ με την εντολή

docker build -t android-build:5.4-28-27 .

Παράμετρος -t ορίζει την ετικέτα ή το όνομα του κοντέινερ μας, το οποίο συνήθως αποτελείται από το όνομα και την έκδοσή του. Στην περίπτωσή μας, το ονομάσαμε android-build και στην έκδοση καθορίσαμε έναν συνδυασμό εκδόσεων gradle, android-sdk και platform-tools. Στο μέλλον, θα είναι ευκολότερο για εμάς να αναζητήσουμε την εικόνα που χρειαζόμαστε ονομαστικά χρησιμοποιώντας μια τέτοια «έκδοση».

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

Για παράδειγμα, ας φτιάξουμε ένα τοπικό έργο. Για να το κάνετε αυτό, στο φάκελο του έργου, εκτελέστε την εντολή

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 gradle assembleDebug

Ας καταλάβουμε τι σημαίνει:

τρέξιμο λιμανιού - η ίδια η εντολή εκκίνησης εικόνας
-rm - σημαίνει ότι μετά τη διακοπή του δοχείου, διαγράφει όλα όσα δημιουργήθηκαν κατά τη διάρκεια της ζωής του
-v "$PWD":/home/gradle/ - προσαρτά τον τρέχοντα φάκελο με το έργο μας Android στον εσωτερικό φάκελο του κοντέινερ /home/gradle/
-w /home/gradle - ορίζει τον κατάλογο εργασίας του κοντέινερ
android-build: 5.4.1-28-27 - το όνομα του δοχείου μας που έχουμε συγκεντρώσει
gradle assembleDebug - η ίδια η ομάδα κατασκευής, η οποία συναρμολογεί το έργο μας

Εάν όλα πάνε καλά, τότε μετά από μερικά δευτερόλεπτα / λεπτά θα δείτε κάτι σαν ΚΑΤΑΣΚΕΥΗ ΕΠΙΤΥΧΗΣ σε 8m 3s! Και στον φάκελο app/build/output/apk θα υπάρχει μια συναρμολογημένη εφαρμογή.

Ομοίως, μπορείτε να εκτελέσετε άλλες εργασίες gradle - ελέγξτε το έργο, εκτελέστε δοκιμές κ.λπ. Το κύριο πλεονέκτημα είναι ότι αν χρειαστεί να δημιουργήσουμε το έργο σε οποιοδήποτε άλλο μηχάνημα, δεν χρειάζεται να ανησυχούμε για την εγκατάσταση ολόκληρου του περιβάλλοντος και θα είναι αρκετό να κατεβάσουμε την απαραίτητη εικόνα και να εκτελέσουμε την κατασκευή σε αυτό.

Το κοντέινερ δεν αποθηκεύει καμία αλλαγή και κάθε συγκρότημα εκκινείται από την αρχή, γεγονός που, αφενός, εγγυάται την ταυτότητα του συγκροτήματος ανεξάρτητα από το πού εκκινείται, αφετέρου, κάθε φορά που πρέπει να κάνετε λήψη όλων των εξαρτήσεων και μεταγλωττίστε ξανά όλο τον κώδικα, και αυτό μερικές φορές μπορεί να πάρει σημαντικό χρόνο. Επομένως, εκτός από τη συνηθισμένη «κρύα» εκκίνηση, έχουμε τη δυνατότητα να ξεκινήσουμε τη συναρμολόγηση διατηρώντας το λεγόμενο. "cache", όπου αποθηκεύουμε τον φάκελο ~/.gradle αντιγράφοντας τον απλά στον φάκελο εργασίας του έργου, και στην αρχή της επόμενης κατασκευής τον επιστρέφουμε πίσω. Μετακινήσαμε όλες τις διαδικασίες αντιγραφής σε ξεχωριστά σενάρια και η ίδια η εντολή εκκίνησης άρχισε να μοιάζει με αυτό

docker run --rm -v "$PWD":/home/gradle/ -w /home/gradle android-build:5.4.1-28-27 /bin/bash -c "./pre.sh; gradle assembleDebug; ./post.sh"

Ως αποτέλεσμα, ο μέσος χρόνος κατασκευής του έργου μειώθηκε αρκετές φορές (ανάλογα με τον αριθμό των εξαρτήσεων του έργου, αλλά ο μέσος όρος του έργου άρχισε να δημιουργείται σε 1 λεπτό αντί για 5 λεπτά).

Όλα αυτά από μόνα τους έχουν νόημα μόνο εάν έχετε τον δικό σας εσωτερικό διακομιστή CI / CD, τον οποίο υποστηρίζετε εσείς οι ίδιοι. Τώρα, όμως, υπάρχουν πολλές υπηρεσίες cloud στις οποίες επιλύονται όλα αυτά τα προβλήματα και δεν χρειάζεται να ανησυχείτε για αυτό, ενώ οι απαραίτητες ιδιότητες κατασκευής μπορούν επίσης να καθοριστούν στις ρυθμίσεις του έργου.

Μόνο εγγεγραμμένοι χρήστες μπορούν να συμμετάσχουν στην έρευνα. Συνδεθείτε, Σας παρακαλούμε.

Διατηρείτε εσωτερικό το σύστημα CI/CD ή χρησιμοποιείτε υπηρεσία τρίτων

  • Χρήση εσωτερικού διακομιστή

  • Χρήση εξωτερικής υπηρεσίας

  • Δεν χρησιμοποιούμε CI/CD

  • Άλλος

Ψήφισαν 42 χρήστες. 16 χρήστες απείχαν.

Πηγή: www.habr.com

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