We need more CDK examples In this github repo we focus on examples for every day work. While there are some nice examples for the fancy stuff like fargate, ecs and so on in aws-cdk-examples/typescript at master · aws-samples/aws-cdk-examples · GitHub, i felt that basic examples where missing. So we created GitHub - tecracer/cdk-templates: Templates for aws cdk
Getting around circular CloudFormation dependencies Several posts complain about the inability of CloudFormation to apply a Lambda event function to an S3 Bucket with an dynamically generated name. The standard UseCase is an S3 Bucket with a Lambda event notification. In this special case the Bucket has a dynamically generated name. This cannot be done by pure CloudFormation! How to work around this circular depency? Let me show you an easy way:
Vergleich Infrastructure as Code (IaC) Frameworks - tRick Alle Posts Abstraktion und Lines of Code Geschwindigkeit Diversity (polyglott), Tooling, Fazit Benchmark Ausführungsgeschindigkeit Ausführungsgeschwindigkeit Direkt aus dem tRick Repository wird mehrfach (n=10) der Zyklus Build -> Check -> Deploy -> Remove ausgeführt. Damit sollen Cache Effekte statistisch gemittelt werden. Dazu nehme ich das Tool hyperfine zur Hilfe. Es führt Kommandos automatisch mehrfach aus und mittelt die Ergebnisse. Meine Annahme ist es, dass Terraform vorne liegt, da das Programm selber statisch kompiliert in go geschrieben ist. Außerdem geht die Ausführung direkt auf die API.
Vergleich Infrastructure as Code (IaC) Frameworks - tRick Teil 3 Alle Posts Abstraktion und Lines of Code Geschwindigkeit Diversity (polyglott), Tooling, Fazit
Managing multiple environments in Terraform Introduction I recently started learning Terraform. For those who haven’t encountered it: Terraform is in essence a framework to describe Infrastructure as code by Hashicorp. When I began doing that, I was struggling with the staging-concept of Terraform. I did my research and came upon numerous 1 articles and blogs that described ways to manage (multiple) environments or stages in Terraform2. Since I wasn’t really happy with the other solutions and there didn’t seem to be a canonical way to handle multiple environments, I decided to try and figure out my own solution.
Note: An updated version of this post is available here Building Lambda Functions with Terraform Introduction Many of us use Terraform to manage our infrastructure as code. As AWS users, Lambda functions tend to be an important part of our infrastructure and its automation. Deploying - and especially building - Lambda functions with Terraform unfortunately isn’t as straightforward as I’d like. (To be fair: it’s very much debatable whether you should use Terraform for this purpose, but I’d like to do that - and if I didn’t, you wouldn’t get to read this article, so let’s continue)
Vergleich Infrastructure as Code (IaC) Frameworks - tRick Ein Toolvergleich für Infrastructure as Code. Um effektiv AWS oder generell Cloud Ressourcen zu erzeugen, verwendet man zur Erhöhung des Automatisierungsgrades “Infrastracture as Code”, d.h. die Server, Datenbanken usw. werden in einer Sprache kodiert. Dieser Vorgang wird sinvollerweise über ein Framework, welches Tools dafür zur Verfügung stellt unterstützt. Aber für welches Tool/Framework entscheidet man sich? Hier werden wir mit Dimensionen für den tRick Benchmark Entscheidungshilfen geben.
Jenkins als Build Server erfreut sich einer großen Verbreitung. Die architekturelle Frage, die sich dabei stellt ist: Wie groß lege ich den Server aus, damit er neben des Management der Build Projekte auch die Builds selber verarbeiten kann? Die einfachste Antwort darauf ist ja: AWS CodeBuild verwenden, aber wenn das nicht geht? Dann bietet das EC2-Plugin eine dynamische Lösung mit AWS Mitteln: Die Worker Knoten werden vollautomatisch dynamisch als EC2 Instanzen erzeugt und wieder abgebaut.
