2015-07-17 6 views
16

Desidero automatizzare la distribuzione della mia applicazione avviando il servizio ECS con l'ultima immagine Docker. Da quello che ho letto, il modo di distribuire una nuova versione dell'immagine è il seguente:Servizio ECS - Automazione della distribuzione con la nuova immagine Docker

  1. Creare una nuova revisione di attività (dopo aver aggiornato l'immagine sul repository Docker).
  2. Aggiorna il servizio e specifica la nuova revisione.

Questo sembra funzionare, ma voglio farlo tutto tramite CLI in modo da poterlo scrivere. # 2 sembra abbastanza facile da fare attraverso la CLI di AWS con update-service, ma non vedo un modo per fare # 1 senza specificare l'intero JSON dell'attività tutto da capo come con register-task-definition (il mio JSON includerà le credenziali nelle variabili di ambiente, quindi io voglio averlo nel minor numero possibile di posti).

È questo il modo in cui dovrei automatizzare la distribuzione degli aggiornamenti del servizio ECS? E se sì, c'è un modo "buono" per far sì che la definizione di attività lanci una nuova revisione (cioè senza duplicare tutto)?

+2

Il trucco è che 'describe-task-definition 'conterrà la definizione del compito originale con _containerDefinitions_ come chiave. Ho avuto successo con la modifica di questo, quindi eseguendo 'register-task-definition' per registrare una nuova definizione. Se sei preoccupato per ENV, la soluzione più semplice è utilizzare uno degli SDK non bash. –

risposta

12

Sì, questo è l'approccio corretto.

E no, con l'API corrente, non è possibile registrare una nuova revisione di una definizione di attività esistente senza duplicarla.

Se non si utilizza la CLI per generare la definizione compito originale (o non si vuole riutilizzare i comandi originali che l'hanno generata), si potrebbe provare qualcosa di simile a quanto segue attraverso la CLI:

OLD_TASK_DEF=$(aws ecs describe-task-definition --task-definition <task_family_name>) 
NEW_CONTAINER_DEFS=$(echo $OLD_TASK_DEF | jq '.taskDefinition.containerDefinitions' | jq '.[0].image="<new_image_name>"') 
aws ecs register-task-definition --family <task_family_name> --container-definitions "'$(echo $NEW_CONTAINER_DEFS)'" 

Non sicuro al 100% poiché l'argomento --container-defintions dell'ultimo comando (che include le voci "environment") sarà ancora visibile tramite processi come ps. Uno degli SDK di AWS offrirebbe maggiore tranquillità.

+0

Potrebbe anche essere necessario altre sezioni come i volumi. Basta usare jq per analizzarlo, quindi aggiungere le opzioni (ad es. --volumes VOLUMES_DEF) alla 'register-task-definition ' –

4

La risposta fornita da Matt Callanan non ha funzionato per me: ho ricevuto un errore su questa parte:

--container-definitions "'$(echo $NEW_CONTAINER_DEFS)'" 

stata: Errore durante l'analisi del parametro '--container-definizioni': Previsto: '=' , ha ricevuto: '' 'per l'ingresso:

' {ambiente: [{etc etc ....

Quello che ho fatto per risolvere il problema era:

TASK_FAMILY=<task familiy name> 
DOCKER_IMAGE=<new_image_name> 
LATEST_TASK_DEFINITION=$(aws ecs describe-task-definition --task-definition ${TASK_FAMILY}) 

echo $LATEST_TASK_DEFINITION \ 
    | jq '{containerDefinitions: .taskDefinition.containerDefinitions, volumes: .taskDefinition.volumes}' \ 
    | jq '.containerDefinitions[0].image='\"${DOCKER_IMAGE}\" \ 
    > /tmp/tmp.json 

aws ecs register-task-definition --family ${TASK_FAMILY} --cli-input-json file:///tmp/tmp.json 

Prendo entrambi gli elementi containerDefinitions e volumi dal documento json originale, poiché containerDefinition utilizza questi volumi (quindi non è necessario se non si utilizzano i volumi).