Chaos Engineering for Containerized Applications with Multi-Version Deployments

It is common practice to use versioning policies to create unique identifiers for applications running in production. Many times the schema used for the versioning identifier also includes information which allows one to infer the impact of the changes bundled in this new version. One well known and frequently used versioning policy is semantic versioning (SemVer), which, if properly adhered to, can be used to determine which different versions can be used interchangeably. However, many systems depending on the semantic versions of their applications do not explore the version compatibility in their applications. Therefore never obtaining confidence about whether the application adheres to the version compatibility promises made by adopting semantic versioning. In this thesis, we present a novel approach to applying chaos engineering practices perturbing containerized application deployments. These perturbations create multi-version execution environments, where multiple different versions of the application are running concurrently. To achieve these multi-version deployments we created the container-registryproxy (CRP), which applies proxy practices to perturb the container distribution protocol. The employed perturbation model targets the versioning of SemVer container images. When a container image is distributed, the perturbation engine serves any image compatible according to SemVer, picked at random. Consequently, deployments with multiple containers are likely to end up running multiple versions. The CRP is evaluated against distributed deployments of two popular databases: PostgreSQL and Redis. We find that the PostgreSQL image for redundant PostgreSQL clusters distributed by Bitnami bundles additional tooling. Incompatibilities between these bundled tools were not reflected in the version identifier according to SemVer, causing multi-version deployments to encounter crashes and take longer before being able to handle requests. None of our multi-version deployments of Redis caused containers to crash nor did it take longer to be operational than version wise homogeneous deployments. Det är vanligt att använda versioneringsprinciper för att skapa unika identifierare för applikationer som körs i produktion. Många gånger innehåller versionsschemat också information som gör att man kan dra slutsatsen om förändringarna i den nya versionen. En välkänd och gångbar versioneringspolicy är semantisk versionering (SemVer), som om den följs ordentligt kan tillämpas för att bestämma vilka olika versioner som omväxlande kan användas. Men många system, som är beroende på semantiska versionerna av deras applikationer, utforskar inte versionskompatibiliteten i sina applikationer. Därför får du aldrig förtroende för om applikationen fäster till versionkompatibilitets löften genom att anta semantisk versionshantering. I denna avhandling presenterar vi ett nytt tillvägagångssätt för att tillämpa kaotekniska metoder för störning av containeriserade applikations driftsättningar. Dessa störningar skapar exekveringsmiljöer med flera versioner, där flera olika versioner av applikationen körs samtidigt. För att uppnå dessa multi-version distributioner skapade vi en container-registry-proxy (CRP), som tillämpar proxy-metoder för att störa container distributions protokollet. Den applicerade störningsmodellen är inriktad på versionering av SemVer- -containerbilder. När en containerbild distribueras betjänar störningsmotorn alla bilder som är kompatibla enligt SemVer, plockade slumpmässigt. Följaktligen kommer distributioner med flera containrar sannolikt att hamna köra flera versioner. CRP utvärderas mot distribuerad distributioner av två populära databaser: PostgreSQL och Redis. Vi finner att PostgreSQL-bilden för redundanta PostgreSQL-kluster som distribueras av Bitnami buntar ytterligare verktyg. Inkompatibiliteter mellan dessa medföljande verktyg återspeglades inte i versionidentifieraren enligt SemVer, vilket orsakade multi-version distributioner att stöta på kraschar och ta längre tid innan de kunde hantera förfrågningar. Ingen av våra multi-version installationer av Redis orsakade att containrar kraschade och det tog inte längre tid att vara i drift än versionvisa homogena distributioner