ProHoster > blog > amministrazione > Creazione di un progetto Android in un contenitore Docker

Creazione di un progetto Android in un contenitore Docker

Quando si sviluppa un progetto per la piattaforma Android, anche il più piccolo, prima o poi bisogna fare i conti con l'ambiente di sviluppo. Oltre all'SDK di Android, è necessario disporre dell'ultima versione di Kotlin, Gradle, platform-tools, build-tools. E se sulla macchina dello sviluppatore tutte queste dipendenze vengono risolte in misura maggiore utilizzando l'IDE di Android Studio, quindi sul server CI / CD ogni aggiornamento può trasformarsi in un mal di testa. E se nello sviluppo web, Docker è diventata la soluzione standard al problema dell'ambiente, allora perché non provare a risolvere un problema simile con esso nello sviluppo Android ...

Per coloro che non sanno cosa sia Docker, se è abbastanza semplice, allora questo è uno strumento per creare il cosiddetto. "Contenitori" che contengono il kernel minimo del sistema operativo e il set di software necessario che possiamo distribuire dove vogliamo, mantenendo l'ambiente. Ciò che sarà esattamente nel nostro contenitore è determinato nel Dockerfile, che viene quindi assemblato in un'immagine che può essere avviata ovunque e ha proprietà di idempotenza.

Il processo di installazione e le basi di Docker sono magnificamente descritti da lui il sito ufficiale. Pertanto, guardando avanti un po ', abbiamo un tale 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"

Lo salviamo nella cartella con il nostro progetto Android e iniziamo a costruire il contenitore con il comando

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

Parametro -t imposta il tag o il nome del nostro contenitore, che di solito consiste nel suo nome e nella sua versione. Nel nostro caso, l'abbiamo chiamato android-build e nella versione abbiamo specificato una combinazione di versioni gradle, android-sdk e platform-tools. In futuro, sarà più facile per noi cercare l'immagine di cui abbiamo bisogno per nome utilizzando una tale "versione".

Dopo che la build è passata, possiamo usare la nostra immagine in locale, possiamo scaricarla con il comando spinta mobile a un repository di immagini pubblico o privato per scaricarlo su altre macchine.

Ad esempio, costruiamo un progetto locale. Per fare ciò, nella cartella del progetto, eseguire il comando

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

Scopriamo cosa significa:

run docker - il comando di avvio dell'immagine stesso
-rm - significa che dopo aver fermato il contenitore, cancella tutto ciò che è stato creato durante la sua vita
-v "$PWD":/home/gradle/ - monta la cartella corrente con il nostro progetto Android nella cartella interna del contenitore /home/gradle/
-w /home/grado - imposta la directory di lavoro del contenitore
Android build: 5.4.1-28-27 - il nome del nostro contenitore che abbiamo raccolto
gradle assembleDebug - il team di costruzione stesso, che assembla il nostro progetto

Se tutto va bene, dopo un paio di secondi / minuti vedrai qualcosa di simile COSTRUISCI CON SUCCESSO in 8m 3s! E nella cartella app/build/output/apk ci sarà un'applicazione assemblata.

Allo stesso modo, puoi eseguire altre attività gradle: controllare il progetto, eseguire test, ecc. Il vantaggio principale è che se dobbiamo compilare il progetto su qualsiasi altra macchina, non dobbiamo preoccuparci di installare l'intero ambiente, e sarà sufficiente scaricare l'immagine necessaria ed eseguire la build in essa.

Il contenitore non memorizza alcuna modifica e ogni assembly viene avviato da zero, il che, da un lato, garantisce l'identità dell'assembly indipendentemente da dove viene avviato, dall'altro ogni volta che devi scaricare tutte le dipendenze e compilare di nuovo tutto il codice, e questo a volte può richiedere molto tempo. Pertanto, oltre al solito avvio "a freddo", abbiamo la possibilità di avviare il montaggio mantenendo il cosiddetto. "cache", dove salviamo la cartella ~/.gradle semplicemente copiandola nella cartella di lavoro del progetto, e all'inizio della build successiva la restituiamo. Abbiamo spostato tutte le procedure di copia in script separati e il comando di avvio stesso ha cominciato ad assomigliare a questo

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"

Di conseguenza, il tempo medio di costruzione del progetto è stato ridotto di diverse volte (a seconda del numero di dipendenze dal progetto, ma il progetto medio ha quindi iniziato a costruire in 1 minuto invece di 5 minuti).

Tutto questo di per sé ha senso solo se hai il tuo server CI / CD interno, che tu stesso supporti. Ma ora ci sono molti servizi cloud in cui tutti questi problemi sono risolti e non devi preoccuparti, e le proprietà di build necessarie possono essere specificate anche nelle impostazioni del progetto.

Solo gli utenti registrati possono partecipare al sondaggio. AccediPer favore.

Mantieni il tuo sistema CI/CD interno o utilizzi un servizio di terze parti

  • Utilizzando un server interno

  • Utilizzo di un servizio esterno

  • Non usiamo CI/CD

  • Altro

42 utenti hanno votato. 16 utenti si sono astenuti.

Fonte: habr.com

Aggiungi un commento