Configurare GitHub Enterprise Server in soluzione Azure VMware

Questo articolo illustra come configurare GitHub Enterprise Server, la versione "locale" di GitHub.com, nel cloud privato soluzione Azure VMware. Lo scenario illustra un'istanza di GitHub Enterprise Server che può servire fino a 3.000 sviluppatori che eseguono fino a 25 processi al minuto in GitHub Actions. Include la configurazione delle funzionalità di anteprima (al momento della scrittura), ad esempio GitHub Actions. Per personalizzare la configurazione per esigenze specifiche, esaminare i requisiti elencati in Installazione di GitHub Enterprise Server in VMware.

Operazioni preliminari

GitHub Enterprise Server richiede un codice di licenza valido. È possibile iscriversi per ottenere una licenza di valutazione. Se si vogliono estendere le funzionalità di GitHub Enterprise Server tramite un'integrazione, verificare se si è idonei per una licenza gratuita per sviluppatori a cinque posti. Richiedere questa licenza tramite il Programma per i partner di GitHub.

Installare GitHub Enterprise Server in VMware

1. Scaricare la versione corrente di GitHub Enterprise Server per VMware ESXi/vSphere (OVA) e distribuire il modello OVA scaricato.

   

   

2. Specificare un nome riconoscibile per la nuova macchina virtuale, ad esempio GitHubEnterpriseServer. Non è necessario includere i dettagli della versione nel nome della macchina virtuale, perché questi dettagli diventano obsoleti quando l'istanza viene aggiornata.

3. Selezionare tutte le impostazioni predefinite per il momento (dettagli da modificare in un secondo momento) e attendere l'importazione dell'OVA.

4. Dopo l'importazione, modificare la configurazione hardware in base alle esigenze. Nello scenario di esempio è necessaria la configurazione seguente.

   Conto risorse	Configurazione standard	Configurazione standard + "Funzionalità beta" (azioni)
   vCPU	4	8
   Memoria	32 GB	61 GB
   Archivio collegato	250 GB	300 GB
   Archiviazione radice	200 GB	200 GB

   Le tue esigenze possono variare. Vedere le indicazioni sulle considerazioni sull'hardware in Installazione di GitHub Enterprise Server in VMware. Vedere anche Aggiunta di risorse di CPU o memoria per VMware per personalizzare la configurazione hardware in base alla situazione in uso.

Configurare l'istanza di GitHub Enterprise Server

Dopo aver attivato la macchina virtuale di cui è stato appena effettuato il provisioning, configurarla tramite il browser. È necessario caricare il file di licenza e impostare una password della console di gestione. Assicurarsi di annotare questa password da qualche parte sicura.

È consigliabile eseguire almeno i passaggi seguenti:

1. Caricare una chiave SSH pubblica nella console di gestione in modo da poter accedere alla shell amministrativa tramite SSH.

2. Configurare TLS nell'istanza in modo che sia possibile usare un certificato firmato da un'autorità di certificazione attendibile. Applicare le impostazioni.

   

3. Durante il riavvio dell'istanza, configurare l'archiviazione BLOB per GitHub Actions.

   Nota

   GitHub Actions è attualmente disponibile come versione beta limitata in GitHub Enterprise Server versione 2.22.

   L'archiviazione BLOB esterna è necessaria per abilitare GitHub Actions in GitHub Enterprise Server (attualmente disponibile come funzionalità "beta"). Le azioni usano questa risorsa di archiviazione BLOB esterna per archiviare elementi e log. Azioni in GitHub Enterprise Server supporta Archiviazione BLOB di Azure come provider di archiviazione (e altri). È necessario creare un nuovo account di archiviazione di Azure con un tipo di account di archiviazione BlobStorage.

   

4. Al termine della nuova distribuzione della risorsa BlobStorage, salvare il stringa di connessione (disponibile in Chiavi di accesso) da usare in un secondo momento.

5. Dopo il riavvio dell'istanza, creare un nuovo account amministratore nell'istanza di . Assicurarsi di prendere nota anche della password dell'utente.

   

Altri passaggi di configurazione

Per rafforzare la protezione avanzata dell'istanza per l'uso in produzione, sono consigliati i passaggi di configurazione facoltativi seguenti:

1. Configurare la disponibilità elevata per la protezione da:

   • Arresti anomali del software (livello di sistema operativo o applicazione)
   • Errori hardware (archiviazione, CPU, RAM e così via)
   • Errori del sistema host di virtualizzazione
   • Rete logicamente o fisicamente interrotta

2. Configurare le utilità di backup, fornendo snapshot con controllo delle versioni per il ripristino di emergenza, ospitati in disponibilità separati dall'istanza primaria.

3. Configurare l'isolamento del sottodominio, usando un certificato TLS valido, per attenuare lo scripting tra siti e altre vulnerabilità correlate.

Configurare lo strumento di esecuzione di GitHub Actions

Nota

GitHub Actions è attualmente disponibile come versione beta limitata in GitHub Enterprise Server versione 2.22.

A questo punto, è necessario avere un'istanza di GitHub Enterprise Server in esecuzione, con un account amministratore creato. È anche necessario disporre di un archivio BLOB esterno usato da GitHub Actions per la persistenza.

Creare un percorso per l'esecuzione di GitHub Actions usando soluzione Azure VMware.

1. Effettuare il provisioning di una nuova macchina virtuale nel cluster e basarla su una versione recente di Ubuntu Server.

   

2. Continuare con la configurazione selezionando la risorsa di calcolo, l'archiviazione e la compatibilità.

3. Selezionare il sistema operativo guest che si vuole installare nella macchina virtuale.

   

4. Dopo aver creato la macchina virtuale, accenderla e connetterla tramite SSH.

5. Installare l'applicazione runner Actions, che esegue un processo da un flusso di lavoro di GitHub Actions. Identificare e scaricare la versione più recente di Linux x64 dello strumento di esecuzione azioni, dalla pagina delle versioni o eseguendo lo script rapido seguente. Questo script richiede che curl e jq siano presenti nella macchina virtuale.

   LATEST\_RELEASE\_ASSET\_URL=$( curl https://api.github.com/repos/actions/runner/releases/latest | \
   
   jq -r '.assets | .[] | select(.name | match("actions-runner-linux-arm64")) | .url' )
   
   DOWNLOAD\_URL=$( curl $LATEST\_RELEASE\_ASSET\_URL | \
   
   jq -r '.browser\_download\_url' )
   
   curl -OL $DOWNLOAD\_URL
   

   È ora necessario avere un file in locale nella macchina virtuale, actions-runner-linux-arm64-*.tar.gz. Estrarre questo tarball localmente:

   tar xzf actions-runner-linux-arm64-\*.tar.gz
   

   Questa estrazione decomprime alcuni file in locale, inclusi uno config.sh script e run.sh .

Abilitare GitHub Actions

Nota

GitHub Actions è attualmente disponibile come versione beta limitata in GitHub Enterprise Server versione 2.22.

Configurare e abilitare GitHub Actions nell'istanza di GitHub Enterprise Server.

1. Accedere alla shell amministrativa dell'istanza di GitHub Enterprise Server tramite SSH e quindi eseguire i comandi seguenti:

2. Impostare una variabile di ambiente contenente l'archivio BLOB stringa di connessione.

   export CONNECTION\_STRING="<your connection string from the blob storage step>"
   

3. Configurare l'archiviazione delle azioni.

   ghe-config secrets.actions.storage.blob-provider azure
   
   ghe-config secrets.actions.storage.azure.connection-string "$CONNECTION\_STRING`      
   

4. Applicare le impostazioni.

   ghe-config-apply
   

5. Eseguire un controllo preliminare per installare più software richiesto da Actions in GitHub Enterprise Server.

   ghe-actions-precheck -p azure -cs "$CONNECTION\_STRING"
   

6. Abilitare le azioni e riapplicare la configurazione.

   ghe-config app.actions.enabled true
   
   ghe-config-apply      
   

7. Controllare l'integrità dell'archiviazione BLOB.

   ghe-actions-check -s blob
   

   Verrà visualizzato l'output: l'archiviazione BLOB è integra.

8. Ora che GitHub Actions è configurato, abilitarlo per gli utenti. Accedere all'istanza di GitHub Enterprise Server come amministratore e selezionare nell'angolo in alto a destra di qualsiasi pagina.

9. Nella barra laterale sinistra selezionare Panoramica dell'organizzazione, quindi Criteri, Azioni e selezionare l'opzione per abilitare Azioni per tutte le organizzazioni.

10. Configurare lo strumento di esecuzione dalla scheda Strumenti di esecuzione self-hosted . Selezionare Aggiungi nuovo e quindi Nuovo strumento di esecuzione nell'elenco a discesa. Viene visualizzato un set di comandi da eseguire.

11. Copiare il comando per configurare lo strumento di esecuzione, ad esempio:

    ./config.sh --url https://10.1.1.26/enterprises/octo-org --token AAAAAA5RHF34QLYBDCHWLJC7L73MA
    

12. Copiare il config.sh comando e incollarlo in una sessione nello strumento di esecuzione azioni (creato in precedenza).

    

13. Usare il ./run.sh comando per eseguire lo strumento di esecuzione:

    Suggerimento

    Per rendere questo strumento di esecuzione disponibile per le organizzazioni dell'organizzazione, modificare l'accesso all'organizzazione. È possibile limitare l'accesso a un subset di organizzazioni e persino a repository specifici.

    

(Facoltativo) Configurare GitHub Connect

Anche se questo passaggio è facoltativo, è consigliabile usare azioni open source disponibili in GitHub.com. Consente di basarsi sul lavoro di altri utenti facendo riferimento a queste azioni riutilizzabili nei flussi di lavoro.

Per abilitare GitHub Connect, seguire la procedura descritta in Abilitazione dell'accesso automatico alle azioni GitHub.com tramite GitHub Connect.

Dopo aver abilitato GitHub Connect, selezionare l'opzione Server to use actions from GitHub.com in workflow runs .Once GitHub Connect is enabled, select the Server to use actions from GitHub.com in workflow runs option.

Configurare ed eseguire il primo flusso di lavoro

Ora che Actions e GitHub Connect sono stati configurati, è possibile usare tutto questo lavoro. Di seguito è riportato un flusso di lavoro di esempio che fa riferimento all'eccellente octokit/request-action, consentendo di "creare uno script" di GitHub tramite interazioni usando l'API GitHub, basata su GitHub Actions.

In questo flusso di lavoro di base usare octokit/request-action per aprire un problema in GitHub usando l'API.

Nota

GitHub.com ospita l'azione, ma quando viene eseguita in GitHub Enterprise Server, usa automaticamente l'API GitHub Enterprise Server.

Se si sceglie di non abilitare GitHub Connect, è possibile usare il flusso di lavoro alternativo seguente.

1. Passare a un repository nell'istanza e aggiungere il flusso di lavoro precedente come segue: .github/workflows/hello-world.yml

   

2. Nella scheda Azioni del repository attendere l'esecuzione del flusso di lavoro.

   

   È possibile vederlo in fase di elaborazione.

   

Se tutto è stato eseguito correttamente, verrà visualizzato un nuovo problema nel repository, intitolato "Hello world".

Complimenti. È stato appena completato il primo flusso di lavoro Actions in GitHub Enterprise Server, in esecuzione nel cloud privato soluzione Azure VMware.

Questo articolo configura una nuova istanza di GitHub Enterprise Server, equivalente self-hosted di GitHub.com, oltre al cloud privato soluzione Azure VMware. L'istanza include il supporto per GitHub Actions e usa Archiviazione BLOB di Azure per la persistenza di log e artefatti. Ma stiamo solo graffiando la superficie di ciò che è possibile fare con GitHub Actions. Vedere l'elenco delle azioni nel Marketplace di GitHub o crearne di personalizzate.

Passaggi successivi

Ora che è stata illustrata la configurazione di GitHub Enterprise Server nel cloud privato soluzione Azure VMware, vedere altre informazioni:

• Come iniziare a usare GitHub Actions
• Come partecipare al programma beta
• Amministrazione di GitHub Enterprise Server