Press "Enter" to skip to content

Automatizujeme Unity v AWS: Příprava prostředí

Zechy 0

Kdo to dneska nedělá automaticky, ten není cool. Automatizace procesů jako testování či deployment je dnes alfa-omega. Jak se s radostí po internetu memuje, „strávíš deset dní automatizací něčeho, co ručně uděláš za deset minut“. A nakonec těch strávených deset dní je určitě více výhodné, než to neustále dělat manuálně.

V našem případě si zautomatizujeme build Unity projektu pomocí GitLab a Amazon Web Services (AWS). Budeme tak chtít dosáhnout následujících kroků:

  • GitLab CI spustí pipeline, která nahraje zdrojové kódy do Amazon S3
  • AWS CodeBuild nám za pomoci GameCI provede automatický build projektu z předaných source codes
  • Vzniknuvší build uložíme do Amazon S3

Jednoduché kroky, že ano? Akorát, že to není tak jednoduché jak se může zdát…

Používané služby v tutoriálu je možné využívat v rámci AWS FreeTier.

Použité nástroje

  • GitLab, v mém případě selfmanaged řešení
  • AWS Command Line Interface, pro přístup z git serveru na AWS
  • GameCI, který poskytuje Docker images Unity editoru
  • Amazon S3, který bude sloužit jako úložiště pro zdrojové kody a výsledné artefakty
  • AWS CodeBuild, který provede build process.

Ostatní díly

  1. Tento díl právě čtete
  2. Automatizujeme Unity v AWS: Sestavujeme naší hru

Postup

  1. Příprava prostředí
    1. Amazon S3
      1. Struktura složek
    2. AWS CodeBuild
      1. Konfigurace projektu
      2. Zdrojové kódy
      3. Prostředí
      4. Artefakty a logy
  2. Nastavení Unity Editoru
    1. Požadavek pro manuální aktivaci
    2. Aktivace licence
      1. Proč nepoužít environment variable?

Příprava prostředí

V AWS si budeme potřebovat připravit dvě věci. Nejdříve Amazon S3, na který budeme CodeBuild odkazovat pro zdrojové kódy a následně samozřejmě samostatný CodeBuild.

Amazon S3

Cloudové úložiště souborů, u kterého je jedno, kolik toho do něj nahrajete. Jednoduše řečeno tedy, platí se samozřejmě za využití. Každopádně pokud potřebujete prostor, do kterého můžete ukládat hromadu dat a nestarat se o to, že vám každou chvilku dojde prostor, je S3 ideální řešení. V našem případě samozřejmě i díky tomu, že plně spolupracuje s CodeBuild, založíme si tedy nový bucket.

Jméno Bucketu musí ovšem být jedinečné v celém AWS regionu, je tak dobrou praxí například volit jména, kdy je naše ID suffixem nebo prefixem. Pro zjištění ID stačí kliknout v horním panelu po pravé straně na název svého účtu. Pokud bych měl ID 1122334455, dám tak svému bucketu název 1122334455-codebuild-tutorial.

Název Bucketu
Pojmenování bucketu
Verzování
Verzování souborů v bucketu

Špatným krokem nemusí být samozřejmě zapnout si verzování, pokud nahrajeme do bucketu soubor se stejným názvem, bude nahrazen jeho novou verzí a k dispozici tak máme historii změn tohoto souboru.

Struktura složek

Struktura složek
Struktura složek

Je samozřejmě dobré si i připravit nějakou rozumnou strukturu složek, abychom se v tom všem vyznali. V našem případě tak

  • artifacts/ slouží pro nahrávání výsledných buildů
  • logs/ pro logy z CodeBuild
  • srcs/ složka, do které budeme nahrávat zdrojové kódy
  • unity-logs/ logy, které vygeneruje unity při jednotlivých buildech

AWS CodeBuild

Amazon nabízí několik vývojových nástrojů, které lze využívat, v našem případě si ovšem postačíme s CodeBuild, tato služba je placená podle vybraného prostředí za minuty, které buildem strávíte. Pro přípravu prostředí projdeme přes několik bodů.

Konfigurace projektu

Tím prvním je základní konfigurace projektu. Pojmenování, popis… Je zde i možnost si zapnout Build Badge, tato možnost je ovšem dostupná na čemkoli jiném, jenom ne na S3. Můžeme také omezit počet současných buildů.

projekt

Zdrojové kódy

Další důležitou částí je samozřejmě odkud má naše prostředí čerpat zdrojové kódy, v našem případě tak zvolíme Amazon S3, vybereme bucket, který jsme vytvořili pro CodeBuild a samozřejmě v položce S3 object key or S3 folder nastavíme, kde se budou brát. My se budeme odkazovat na zdrojové kódy uložené v zipu.

Zdrojové kody

Prostředí

Je samozřejmě také podstatné v jakém prostředí to vše spustíme. Teď přichází na řadu Game.CI a jejich docker images, nejlepší je samozřejmě se rovnou odkázat do jejich Dockerhub a vybrat si tu správnou verzi editoru, kterou potřebujeme. V mém případě je to Unity v2020.1.17f1 a v tento okamžik potřebuji pouze Buildy pro windows, já tak zvolím image unityci/editor:ubuntu-2020.1.17f1-windows-mono-0.12.0.

Prostředí

Důležité je taky vybrat si výpočetní výkon, který budeme potřebovat. Pokud míříme na volné minuty z AWS FreeTier, vystačíme si s možností 3 GB memory, 2 vCPUs.

Výpoteční výkon

Artefakty a logy

Nakonec artefakty našich logů, ty ovšem prozatím můžeme nechat vypnuté. Zaměříme se tak na to, aby se nám zapisovaly logy. Podobně jako se zdrojovými kódy, vybereme svůj bucket a předáme cestu k naší logs složce.

Logy

S takto vytvořeným prostředím jsme připraveni na první kroky.

Nastavení Unity Editoru

To by nebylo Unity, aby to nebylo tak jednoduché. Zde přichází ta komplikace o které jsem mluvil na začátku. Budeme muset udělat jeden prázdný build, kterým si vygenerujeme požadavek pro manuální aktivaci, a pak druhý zkušební, kterým si vyzkoušíme, že aktivace opravdu funguje. Pro tyto dva kroky si můžeme připravit zip čistě s našimi skripty, nemusíme implementovat celý Unity projekt.

V tomto kroku se zaměříme na Unity Personal License.

Požadavek pro manuální aktivaci

Nyní už přichází nějaká ta opravdová sranda. Připravíme si složku .ci, která bude obsahovat všechny naše skripty, které v rámci buildu budeme spouštět. V této složce si připravíme skript request-license.sh, který provede vygenerování souboru *.alf, pomocí kterého si obstaráme licenci.

#!/usr/bin/env bash

LOG_OUTPUT=./unity-output.log
ACTIVATION_FILE=./Unity_v2020.1.17f1.alf # Unity generates license file coresponding to version.

echo "Retrieving activation file for Unity"
OUTPUT=$(unity-editor -batchmode -nographics -logFile /dev/stdout -quit -createManualActivationFile)
UNITY_EXIT_CODE=$?
echo "$OUTPUT" > "$LOG_OUTPUT"

if [[ $UNITY_EXIT_CODE -eq 0 ]] || [[ $UNITY_EXIT_CODE -eq 1 ]]; then
  echo "Manual activation file successfuly created"
  echo "Created as artifact $ACTIVATION_FILE"
  exit 0
else
  echo "Error while requesting activation file. Check artifact $LOG_OUTPUT"
  exit $UNITY_EXIT_CODE
fi

V tomto souboru je samozřejmě nutné si upravit ACTIVATION_FILE proměnnou tak, aby odpovídala naší verzi Unity, v mém případě tak verzi v2020.1.17f1.

Ale jak to spustíme? CodeBuild k tomu využívá soubor s názvem buildspec.yml, jedná se o soubor, ve kterém jsou popsány jednotlivé kroky a co se má spustit. My si tak tento soubor nyní připravíme na to, abychom vygenerovali licenční soubor a ten následně nahráli do S3.

version: 0.2

phases:
  install:
    commands:
      - chmod +x ./.ci/request-license.sh
  build:
    commands:
      - ./.ci/request-license.sh
artifacts:
  files:
    - ./Unity_v2020.1.17f1.alf
  secondary-artifacts:
    unityLog:
      files:
        - ./unity-output.log

Nyní tak nastavíme práva na spuštění na našem souboru a při kroku build provedeme vyžádání licence, zároveň si jako artefakt zaregistrujeme náš *.alf soubor. Necháme si ovšem vygenerovat také ještě druhotný artefakt, kdy se nám uloží výstup Unity editoru. Celé to nyní zabalíme do zip archivu, který bude názvem korespondovat tomu, který jsme si definovali, nahrajeme do složky srcs v S3 a půjdeme spustit svůj první build.

Využijeme ovšem k tomu nejdříve možnost Start build with overrides a zvolíme možnost Advanced build overrides. To proto, abychom mohli vydefinovat naše artefakty, které nyní potřebujeme. V kartě Artifacts tak vytvoříme náš primární a pomocí volby Add artifact také nás sekundární.

Artefakt pro Unity License
Definice artefaktu pro Unity license, do složky artifacts, se nahraje odpovídající soubor
Unity Output Artefakt
Sekundární artefakt pro Unity log

Když takto nastavený build necháme proběhnout, objevíme po úspěšném dokončení v našem bucketu ve složce artifacts soubor s názvem Unity_v2020.1.17f.alf (či podle vaší verze) a v unity-logs najdeme unity-output.log.

Soubor *.alf si stáhneme a pokračujeme na stránku https://license.unity3d.com/manual, kde si z něho necháme vygenerovat *.ulf soubor.

Aktivace licence

Jakmile vyplníme dotazník a získáme náš *.ulf soubor, který bude pojmenovaný například jako Unity_v2020.x.ulf, vyzkoušíme si, zda funguje úspěšná aktivace licence. Do naší složky .ci si tak překopírujeme získaný *.ulf soubor a vytvoříme soubor activate.sh.

#!/usr/bin/env bash

OUTPUT_FILE=./unity-output.log
FILE_PATH=./.ci/Unity_v2020.x.ulf

echo "Requesting activation"
OUTPUT=$(unity-editor -batchmode -nographics -logFile /dev/stdout -manualLicenseFile $FILE_PATH -quit)
UNITY_EXIT_CODE=$?
SUCCESS=$(echo "$OUTPUT" | grep 'Next license update check is after' | wc -l)
echo "$OUTPUT" > "$OUTPUT_FILE"

if [[ $SUCCESS -eq 1 ]]; then
  UNITY_EXIT_CODE=0
fi

if [ $UNITY_EXIT_CODE -eq 0 ]; then
  echo "Unity activation completed"
  exit 0
else
  echo "Error during license activation, check $OUTPUT_FILE"
  echo "Unity exit code was: $UNITY_EXIT_CODE"
  exit $UNITY_EXIT_CODE
fi

Opět platí nezapomenout přejmenovat si proměnnou FILE_PATH tak, aby odpovídala názvu našemu souboru.

Unity vezme nyní náš licenční soubor, prověří ho a uloží si ho pro další použití. V proměnné OUTPUT by se tak měl nacházet řetězec Next license update check …, který nám říká, že Unity úspěšně zvalidovalo naší licenci. Pokud tam tento řetězec není, znamená to chybu a vrátíme exit code jiný než nula, abychom tak failnuli náš build. Tento skript v budoucnu budeme pouštět před každým naším buildem.

Nyní je tak na čase upravit náš buildspec.yml.

version: 0.2

phases:
  install:
    commands:
      - chmod +x ./.ci/activate.sh
  build:
    commands:
      - ./.ci/activate.sh
artifacts:
  files:
    - ./unity-output.log

Tentokrát si už jen pro jistotu jako artefakt uložíme log z unity. Tudíž opět spustíme Build with overrides, kde nastavíme pouze jeden artefakt.

Proč nepoužít environment variable?

Nabízí se samozřejmě jasná možnost použít environment variables pro obsah licenčního souboru. To ovšem v případě, že chcete jako já tři dny pátrat, proč build neprochází. Těžko říct, zda je to tím, že env vars se v CodeBuild zadávají přes klasický textinput, a né textarea, do prostředí se ovšem dostane zjevně poškozený řetězec, se kterým si Unity neumí poradit a neověří tak licenci.

Každopádně, pokud vše proběhne jak má, build by měl skončit jako Succeeded, v tomto případě jsme uspěli v nastavení postupu aktivace naší licence a můžeme se pustit do našeho prvního automatického sestavení aplikace. Na to se ovšem podíváme v pokračování tohoto článku!

Další díl: Automatizujeme Unity v AWS: Sestavujeme naší hru

Napsat komentář