Tooling om gecontroleerd IoC te testen

In dit blog geef ik aan welke tooling je kan gebruiken om gecontroleerd IoC te testen

Deployment tools om de JSON/YAML files gecontroleerd te genereren

Terraform:
HashiCorp’s Terraform is een van de populaire open-sourcetools met een goed klantenbestand geschreven in Golang. Het gebruikt configuratiesyntaxis om infrastructuur te beschrijven en de syntaxis wordt HCL genoemd - Hashicorp-configuratietaal. Terraform wordt gebruikt om infrastructuur in te richten/te beheren en te implementeren op verschillende cloudplatforms. Eenvoudige beschrijvende taal en CLI kunnen worden gebruikt om het terraform-plan te valideren, zodat uw eindresultaat aan de verwachtingen voldoet.

AWS CloudFormation:
AWS CloudFormation is een IaC-tool die wordt gebruikt om AWS-infrastructuur en bronnen van derden te modelleren, in te richten en te beheren. YAML- of JSON-sjablonen worden gebruikt om AWS-bronnen te automatiseren. Deze tool heeft een functie om de vorige status terug te draaien als er problemen zijn met de implementatie. U hoeft zich geen zorgen te maken over AWS-afhankelijkheden - deze tool helpt u automatisch de afhankelijkheden op te lossen.

Ansible:
De open source-tool Ansible wordt gebruikt voor het inrichten en configureren van infrastructuur en het beheren van de implementatie van applicaties. Ansible gebruikt YAML om playbook-configuratietalen en variabele bestanden te definiëren.

TESTEN TESTEN TESTEN

Het testen van Infastructure as code is een proces van valideren en verifiëren dat de juiste infrastructuur en middelen zijn ingesteld en geconfigureerd. Er zijn tools beschikbaar.

Het schrijven van geautomatiseerde tests voor geïmplementeerde infrastructuur vereist goede kennis van programmeervaardigheden. Mogelijk moet u verschillende programmeertalen leren. TerraTest gebruikt bijvoorbeeld Golang, terraform-compliance gebruikt Python en AWSSpec gebruikt Ruby enz. Houd hier rekening mee als u van domein(Denk bijv. van Cloud AWS naar Azure) wilt wisselen. Ik gebruik zelf nu CDK omdat ik binnen het AWS domein blijf. In AWS CDK kan met hier Jest voor gebruiken waar ik mezelf in verdiep (javascript en typescript)
https://docs.aws.amazon.com/cdk/v2/guide/testing.html

Unit tests voor deployment

Voordat we deployen is het handig om de relevante configuratie en enkele onderdelen van de applicatie vanuit infrastructuur optiek te testen. Dit maakt het kostenbesparend, tijdbesparend en veilig. Vooral bij het werken aan cloudapplicaties hoeven teams geen honderden dollars uit te geven door verbinding te maken met de eigenlijke cloudresources om uw applicaties in een lokale omgeving te testen. Dit is een potentiële besparing van kosten en tijd. In mijn geval kan het al volstaan als je dit doet in het cdk synth proces Er zijn verschillende opties beschikbaar in verschillende buildtools om de infrastructuurcode te testen voordat deze daadwerkelijk wordt geïmplementeerd.

bijv.
Compiler
-Terraform – Terraform validate command
-CDK 2 - jest library - lib const { Capture, Match, Template } = require(“aws-cdk-lib/assertions”);

Linters
-Cfn-lint
-Terraform- Conftest, terraform_validate, tflint

Dry run – Voer de code gedeeltelijk uit door het “plan” te valideren, maar implementeer het niet daadwerkelijk.

Terraform- terraform-compliance (terraform plan)
CDK Synth

Generic tool denk bijv aan checks om misconfiguraties van policies te analyseren en controleren - https://www.checkov.io/. Dit kan belangrijk zijn voor security doeleinden

MOCKING -Smalle applicatie tests as Code

Na statische analyse is het ook nodig om individuele bestanden te testen. Elk bestand voert bepaalde taken uit zoals gedefinieerd.
Met name voor cloudinfrastructuur kan het definiëren van de strategie voor unit-tests en het gebruik van de gelokaliseerde omgevingstools kosten en tijd besparen. Als onderdeel van unit-tests kunnen we daadwerkelijk implementeren, valideren en destroyen zonder de daadwerkelijke cloudresources te gebruiken. We kunnen ook enkele van de hierboven genoemde technieken gebruiken als onderdeel van het testen van eenheden.

Naast het testen van afzonderlijke modules is het noodzakelijk om integratietesten uit te voeren, waarbij meer dan één onderling gerelateerde module samen wordt getest om een ​​specifiek resultaat te bereiken. Er zijn opties beschikbaar om gebruik te maken van gelokaliseerde omgevingstools en emulators.

LokaleStack:
LocalStack testte AWS-cloud- en serverloze apps, ontwikkelde een mocking-framework voor cloud-applicaties, kosteneffectief testen, lokaal/offline testen, niet afhankelijk van de cloud en gebruiksvriendelijk.

moto:
De Moto AWS SDK voor Python-bibliotheek test eenvoudig op AWS-infrastructuur. Het is een erg handige bibliotheek om AWS-services te mocken.

Azure-functions-core-tools:
Azure-functions-core-tools Opdrachtregelprogramma’s voor Azure Functions en biedt lokale ontwikkelervaring voor Azure-applicaties voor het ontwikkelen, testen, uitvoeren en debuggen van Azure-functies

Azurite-emulator:
Het Azurite-emulatorprogramma dat de Azure Blob-, Queue- en Table-services emuleert voor lokale ontwikkelingsdoeleinden. We kunnen uw applicaties ook lokaal testen tegen de opslagservices zonder verbinding te maken met daadwerkelijke Azure-cloudservices.
Cosmos DB-emulator:
De Azure Cosmos DB-emulator emuleert de Azure Cosmos DB-service en test uw toepassing lokaal zonder een Azure-abonnement te maken.
Testen door te implementeren

Testen door te implementeren

Het testen van infrastructuur als code is vergelijkbaar met het testen van applicatiecode in termen van een testpiramide. Naarmate uw meer automatiseringstestcases voor infrastructuur in de keten gaat schrijven, zullen de kosten, de tijd en de foutgevoeligheid toenemen. Met andere woorden, het testen van de volledige omgeving, vergelijkbaar met “End-to-end testen”, betekent het testen van de volledige implementatieworkflow. Dit omvat het inrichten en configureren van de infrastructuur en het implementeren van de softwaretoepassing. Het doel van deze end-to-end-tests is ervoor te zorgen dat de omgeving zich gedraagt ​​zoals verwacht.

Ergens van de week had ik nog een gesprek met mijn productowner die ik met vele andere productowners managers heb gehad. Dat systeembeheerders vaak cowboys zijn en we moeten ons wel aan regels houden (zeg ik gecharceerd:-) De systeembeheerder had het gevoel dat het niet nodig was om de omgeving te testen. Daardoor was er geen garantie dat de productieomgeving werkte zoals verwacht. Het testen van de omgevingen (d.w.z. infrastructuur + configuraties + geïmplementeerde software) geeft de applicatie een betere kans om te doen wat het moet doen. De meeste issues die ik vaak meekrijg zijn niet eens functionele zaken, maar zitten vaak in de wereld van performance, security en ….. infrastructure. In het verleden kon het niet anders om deze testen handmatig uit te voeren aangezien scripting erg complex is. Maar met die aanpak was er een grote kans op falen of inconsistent gedrag in verschillende omgevingen. Tegenwoordig spelen geautomatiseerde testtools een belangrijke rol bij het testen van infrastructuur. Laten we in het onderstaande gedeelte enkele automatiseringstools doornemen om de infrastructuur te testen.

Terratest
Dit is een Go-bibliotheek, die functies heeft voor het implementeren, valideren en vernietigen. Kan worden gebruikt om infrastructuur te testen die is geschreven in Terraform, Kubernetes, Packer, Docker, Servers, Cloud API’s voor elke cloudserviceprovider zoals AWS, Google Cloud en Kubernetes. We kunnen Terratest gebruiken om echte IaC-tools uit te voeren, echte infrastructuur te implementeren, infrastructuur te valideren en onze geïmplementeerde infrastructuur op te schonen. We kunnen ook unittesten, integratietesten en end-to-endtesten schrijven.

AWSpec:
Om AWS-bronnen en RSpec-bibliotheek te testen
voorbeeld is hier: https://github.com/k1LoW/awspec