integration of compose-like container groups

Aperta
  • Qualcosa non va?
#297 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
20/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
docker, docker-compose
Ambito
devops, testing

Direzione di ricerca

L'issue non indica file, test o punti di ingresso. Inizia esaminando il ciclo di vita dei container esistente e il workflow dei test, quindi confrontane le capacità con la gestione da parte di Docker Compose di gruppi eterogenei di container. Per considerarlo completato sarebbero necessari un ambito concordato e un design per comporre, eseguire e distruggere ripetutamente più sistemi di container all'interno di una suite di test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Although only recently having entered the containers space, I have come to understand the importance of Container Structure Test.

Docker and other developers of container infrastructure emphasize the value of building custom containers for testing general software, even software not generally targeted for containers, but few emphasize the importance of validating a container image before publishing it to external consumers.

The Docker interface is not natively friendly to the workflow of reusing an image for repeated cycles of container creation and destruction, and therefore, management of these processes is an important source of value from this project.

Automation in container testing seems to entail two critical aspects. One, as just explained, is management of the life cycle of a container and automatic processes occurring within the lifetime. The other is management of groups of containers, of heterogeneous source images, related to each other by sharing of otherwise isolated resources, such as network connectivity. Docker Compose seeks to achieve the latter objective.

In the case of robust container testing, I have come to understand, the needed for both of these automation features being integrated into a single, cogent workflow.

To make possible a truly robust test suite, a framework should allow a test suite to include specifications of any number of systems of heterogeneous containers, each such system being created and destroyed any number of times, under various specific constraints or performing various specific tasks, That is, a test suite in general should encapsulate multiple Compose-like definitions, and should handle the entire life cycle of all components from each definition.

It suggest it would be quite worthwhile for Container Structure Tests to move in such an ambitious direction.

Lingua principale
Go
Stelle
2.5k
Fork
213
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di GoogleContainerTools/container-structure-test

Tutte le issue di GoogleContainerTools/container-structure-test

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.