{"id":16179265,"url":"https://github.com/jonashackt/pulumi-talk","last_synced_at":"2026-01-30T06:04:05.912Z","repository":{"id":147270058,"uuid":"213936807","full_name":"jonashackt/pulumi-talk","owner":"jonashackt","description":"Notes and links for my talk on Pulumi","archived":false,"fork":false,"pushed_at":"2020-01-22T06:56:57.000Z","size":19111,"stargazers_count":4,"open_issues_count":0,"forks_count":0,"subscribers_count":2,"default_branch":"master","last_synced_at":"2025-06-09T23:04:25.583Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jonashackt.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2019-10-09T14:13:30.000Z","updated_at":"2022-03-09T20:33:55.000Z","dependencies_parsed_at":null,"dependency_job_id":"9d2f99e4-988f-4033-89a1-16baa8ea953f","html_url":"https://github.com/jonashackt/pulumi-talk","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/jonashackt/pulumi-talk","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonashackt%2Fpulumi-talk","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonashackt%2Fpulumi-talk/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonashackt%2Fpulumi-talk/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonashackt%2Fpulumi-talk/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jonashackt","download_url":"https://codeload.github.com/jonashackt/pulumi-talk/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jonashackt%2Fpulumi-talk/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28906222,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-30T04:02:34.702Z","status":"ssl_error","status_checked_at":"2026-01-30T04:02:33.562Z","response_time":66,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-10-10T05:26:30.110Z","updated_at":"2026-01-30T06:04:05.894Z","avatar_url":"https://github.com/jonashackt.png","language":null,"funding_links":[],"categories":[],"sub_categories":[],"readme":"# pulumi-talk\n[![License](http://img.shields.io/:license-mit-blue.svg)](https://github.com/jonashackt/pulumi-talk/blob/master/LICENSE)\n\nNotes and links for my talk on Pulumi\n\nTalk is available as PDF: [20191113-Pulumi-vs-Ansible-ContainerConf2019.pdf](20191113-Pulumi-vs-Ansible-ContainerConf2019.pdf)\n\nExample projects used in the talk:\n\nhttps://github.com/jonashackt/pulumi-python-aws-ansible\n\nhttps://github.com/jonashackt/pulumi-typescript-aws-fargate\n\n\n### Talk snippets\n\n##### Create Projects Demo\n\n```\nmkdir devopsilmenau \u0026\u0026 cd devopsilmenau\n\npulumi new aws-typescript\n\ncode .\n\npulumi up\n\npulumi destroy\n\npulumi stack rm\n```\n\n\n##### Configuration Drift Demo (Python)\n\nOpen console and enter `pipenv shell`.\n\nOpen projects in IntelliJ\n\nShow `__main__.py` first.\n\n```\npipenv install\n\npulumi destroy --yes\n\nansible-playbook keypair.yml\n\npulumi up\n\nansible-galaxy install -r requirements.yml -p roles/\n\nansible-playbook playbook.yml\n\npy.test -v tests/test_docker.py --ssh-identity-file=.ec2ssh/pulumi_key --ssh-config=tests/pytest_ssh_config --hosts='ssh://'$(pulumi stack output publicIp)\n\npulumi destroy --yes\n```\n\n\n##### Fargate ECS Spring Boot Vue.js Demo (Typescript)\n\n\nOpen projects in IntelliJ\n\nShow `index.ts` first.\n\n```\nnpm install\n\npulumi destroy --yes\n\npulumi up\n\npulumi stack output url\n```\n\nOpen Browser with `url` output incl. port 8098\n\n```\npulumi destroy --yes\n```\n\n\n\n\n#### Why Apples vs. Bananas?\n\nFirst slide: Why Pulumi vs. Ansible?\n\nAsk stackshare.io!! \n\n--\u003e https://stackshare.io/pulumi/alternatives\n\n\n# What is Pulumi?\n\n#### Pulumi? YOUNG! \n\n1.0 in 09/2019 https://www.heise.de/developer/meldung/Infrastructure-as-Code-Die-Plattform-Pulumi-erreicht-Version-1-0-4516570.html\n\nhttps://medium.com/@griggheo/good-devops-tech-skills-to-have-in-2019-75d7102eaf28\n\n\nIn contrast to other Infrastructure-as-Code tools, Pulumi uses real programming languages instead of YAML to define infrastructure code:\n\n\u003e At the center of Pulumi is an open-source cloud object model \u0026 an evaluation runtime (https://www.pulumi.com/docs/intro/concepts/)\n\nThis cloud object model is language agnostic to support multiple programming languages at the same time ([currently Node.js/JavaScript \u0026 Python. And there's a Preview for Go and the possibility to implement your own Language](https://www.pulumi.com/docs/intro/languages/)). The evaluation runtime is knows about the cloud resources and how to plan, manage \u0026 execute them.\n\nPulumi Project is a folder with a `Pulumi.yaml` - create with `pulumi new`. \n\nPulumi Stacks are like stages (dev, stage, production).\n\n\n\n#### Roadmap\n\nRoadmap: https://github.com/pulumi/pulumi/wiki/Roadmap\n\n![backlog](backlog.png)\n\n\n#### Pulumi service backend architecture\n\nhttps://www.pulumi.com/docs/intro/concepts/state/\n\n![pulumi-service-backend-arch](https://www.pulumi.com/images/docs/reference/state_saas.png)\n\nPulumi self-hosted service-backend is only available in \"Pulumi Enterprise\": https://www.pulumi.com/pricing/ :(((\n\n\n#### Pulumi is somehow like a nice Terraform-Wrapper\n\nhttps://www.pulumi.com/docs/intro/vs/terraform/#using-terraform-providers\n\nPulumi is able to adapt any Terraform provider - and many of the most interesting Pulumi providers are derived Terraform providers \n\n--\u003e There's even a Terraform converter: https://www.pulumi.com/docs/intro/vs/terraform/#converting-from-terraform\n\nAnd Terraform and Pulumi could be used together a the same time: https://www.pulumi.com/blog/using-terraform-remote-state-with-pulumi/\n\n\n\n# Comparing Infrastructure-as-Code tools is hard!\n\n!-\u003e; Provisioning vs. Configuration Management tools (see https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c?gi=cfad03e3531b)\n\n__Configure existing servers: Ansible, Chef, Puppet, Saltstack__\n\n__Issues the creation of servers (\"provisioning\"): Cloudformation, Terraform, Pulumi__\n\n----\u003e BUT: the lines blur! Let's have a look at Ansible's cloud modules: https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html\n\ncould do some CM tasks with Terraform, but you can do every single provisioning task with Ansible!\n\n\n### Provision? Yes! Configure? No!\n\nImagine your EC2 instance is running, now we want to install some sort of software on it. How do we issue shell commands and the like with Pulumi?\n\nThe answer is: NOT AT ALL! There's currently no way to do this (see https://github.com/pulumi/pulumi/issues/99). \n\nPulumi website explains why (https://www.pulumi.com/docs/intro/vs/chef_puppet_etc/): \n\n\u003e Chef, Puppet, Ansible, and Salt are all popular configuration management tools. These tools help you install and manage software on existing cloud infrastructure, either for bootstrapping a virtual machine, or patching one. They do not attempt to solve the problem of provisioning or updating infrastructure, containers, or serverless resources.\n  Pulumi is fundamentally different than these tools and works great alongside them. \n\nTaking Ansible as the current leader of IaC tools, the quote \"They do not attempt to solve the problem of provisioning or updating infrastructure\" is simply a lie - [Ansible has a whole bunch of Cloud modules available](https://docs.ansible.com/ansible/latest/modules/list_of_cloud_modules.html) and is able to provision or update nearly anything. \n\nBut the last part is interesting \"Pulumi is fundamentally different than these tools and works great alongside them.\" --\u003e so having the need to configure a system, you should use something like Ansible!\n\nAh interesting... let's have a look into other aspects!\n\n\n\n### The central problem in IaC: configuration drift!\n\nSee https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c#b264\n\n\n\u003e \"The academic comparison\": Mutable vs. Immutable infrastructure\n\n__Mutable: Ansible, Chef, Puppet, Saltstack__\n\n\u003e For example, if you tell Ansible to install a new version of OpenSSL, it’ll run the software update on your existing servers and the changes will happen in-place. Over time, as you apply more and more updates, each server builds up a unique history of changes. This often leads to a phenomenon known as configuration drift,\n\n--\u003e simply: same servers, changed every time. (focus on configuration management)\n\n__Immutable: Pulumi, Terraform__\n\n\u003e If you’re using a provisioning tool such as Terraform to deploy machine images created by Docker or Packer, then every “change” is actually a deployment of a new server. For example, to deploy a new version of OpenSSL, you would create a new image using Packer or Docker with the new version of OpenSSL already installed, deploy that image across a set of totally new servers, and then undeploy the old servers.\n\n--\u003e simply: new servers, every time. (focus on provisioning)\n\n__Opinion__: Like most academic classification, this doesn't apply in practice!\n\n1. In practice, your Infrastructure code isn't performed manually by yourself from the CLI. Hell NO! We have CI/CD systems doing that for us! And as we are doing Infrastructure-as-CODE, we treat this code like any other code! It'll go through stages - from dev/branches, to master/stage to production.\n   --\u003e that means, you only need to look into your CI/CD pipelines (like GitLab CI) to see the state of your servers!\n   --\u003e no configuration drift without git commit possible - and if the drift happens, it is intended\n2. These tools have a focus on one classification - but you can also do things from the other concept to some extend. Have a look at Terraform's [remote-exec Provisioner](https://www.terraform.io/docs/provisioners/remote-exec.html) for example. The only exception is Pulumi right now, but it's on the roadmap.\n   --\u003e No commands on the systems possible right now with Pulumi!!! :((( (see https://github.com/pulumi/pulumi/issues/127 \u0026 https://github.com/pulumi/pulumi/issues/99 \u0026 https://github.com/pulumi/pulumi/issues/1691)\n   --\u003e It's definitely NOT possible to configure a system/server/container whatsoever with Pulumi!!!\n3. If you choose Ansible with it's concept of idempotency! Run your commands once or multiple times: the result will be the same!\n4. If you choose \"shiny immutable infra focuses tool\" + \"servertemplating\", who and what does the term \"servertemplating\" mean? Doesn't it mean, that you pull up a virtual machine/container and configure stuff or install software on it, then pack the result into an image? Ah well, that's nice! So you're doing immutable infrastructure with configuration management tools?! :))))\n\nThat means in most situations you will use multiple tools to get the job done. But this also leads to the problem, that your team has to learn and support multiple IaC tools. I'am personally a fan of reducing the tools you need to learn and master by choosing a framework, that is able to do most of the stuff needed throughout infrastructure development.\n\n\n\u003e So the state of the machine deviates, or drifts, from the baseline due to manual changes and updates. (see https://shadow-soft.com/ansible-idempotency-configuration-drift/)\n\n##### 2 approaches to address configuration drift\n\n1. Rebuild machine instances frequently so they don’t have much time to drift from the baseline.\n\n2. Use Ansible (\u0026 Co.) and run them frequently and repeatedly to keep machines in line\n\n--\u003e See?! It's all about the __frequently__ part! You could also say: continuous! That leads us to modern ways on how to work with Infrastructure code: Continuous infrastructure!\n\n\n\n### What is the current state of my infrastructure?\n\nagain see see https://blog.gruntwork.io/why-we-use-terraform-and-not-chef-puppet-ansible-saltstack-or-cloudformation-7989dad2865c?gi=cfad03e3531b\n\n\u003e Procedural vs. Declarative\n\n__Procedural: Chef, Ansible__\n\n\u003e  they encourage a procedural style where you write code that specifies, step-by-step, how to to achieve some desired end state.\n\n--\u003e simple: step-by-step \"as your code would be the admin\" (and as every tutorial states)\n\n\n__Declarative: Terraform, Pulumi, CloudFormation, SaltStack, Puppet__\n\n\u003e encourage a more declarative style where you write code that specifies your desired end state, and the IAC tool itself is responsible for figuring out how to achieve that state.\n\n--\u003e simple: say what you want, not how. \n\n\nAgain like Mutalbe vs. Immutalbe: What is the core problem, that should be solved?\n\n###### To answer: \"What is the current state of my infrastructure?\" we have 2 approaches:\n\n1. Use a declarative approach and have a look into your code.\n\n2. Simply have a look into your CI/CD pipeline to see what has happened last. \n\n--\u003e In theory, the declaritive approach might \"win\" the battle. I seems more clean and accurate then these \"procedural tools down there in the dust\". \nBut in practice there are some good reasons why procedural approach is maybe better. \n\n1. It's absolutely easy to understand! Every Sysadmin knows after minutes of intro: \"Ah, this thing automates manual tasks for me! Great!\" Try this with Terraform: \"What tell hell is this tool doing behind the scenes?\"\n2. Every tutorial on the web could be easily transformed into procedural code - it's that simple! The declarative tool user simply has a problem, if the needed tool has no provider/module whatsoever for the given task. Or they simply use a procedural tool then ;P\n3. less magic - more understanding, what the tool does\n4. The downside of a procedural tool, that you don't exactly see the current state of your infrastructure solely in the code, could be wiped out with the use of modern CI/CD tools and GitOps workflows (that you should use in exactly the same way with declarative tools)\n\n\n\n### Nobody needs Masters!\n\nAnother comparable feature of IaC tools is if they need a master server for storing state of your infrastructure or not:\n\n__Need a Master server: Chef, Puppet, SaltStack, Pulumi__\n\n(Note: most tools support Masterless modes, but then they rely on Agents with their own downsides)\n\npros: \n* central place to see status of your infrastructure\n* continuously enforce configuration in the background\n\ncons: \n* extra infrastructure!\n* needs to be maintained\n* security: client-to-master and master-to-servers communication needs extra ports to be opened \u0026 extra authentication\n\n\n__Masterless: Ansible, Terraform, CloudFormation__\n\n\n--\u003e again the pros of a master server without the cons of this extra peace of infrastructure can be introduced in pratice by simply using a CI/CD server! No master needed!\n\n\n### Nodoby wants Agents either!\n\n__Need Agent on the managed servers to be installed up front: Chef, Puppet, SaltStack__\n\n(Note: there are Agentless modes in these tools, but they don't support the full featureset)\n\ncons: \n* bootstrapping: how to provision servers \u0026 install needed agent, if they have no agent installed?\n* maintainance of agent: update agent periodically, monitor it\n* security: same as with Master server\n\n\n__No Agent needed (client-only): Ansible, Terraform, Pulumi__\n\npros: no extra problems with bootstrapping, maintainance, security - no extra moving parts!\n\n\n\n\n\n### Is YAML really bad? Or how to transform an organisation with classic Sysadmins\n\n\u003e I know some of the guys here do not like YAML. However, it has its place. Not everyone is completely dev minded. YAML in my opinion is a nice middle ground for more ops guys that are gaining more Dev mentality.\n !!! -\u003e Puppet had the problem with code also (abstraction, classes and so on...)\n (reddit: https://www.reddit.com/r/devops/comments/bcdwsn/pulumi/)\n\nThere are maybe not only god-like code cracks out there! Imaginge the classic Sysadmin -\u003e maybe you could easily \"infect\" somebody like this to use a simple YAML-based approach, that could be written with simple editors. Coming around the corner with a full blown language could maybe overwhelm people?!\n\n\n### The theoretic argument of speed\n\nGoogle `pulumi ec2 module python` vs `ansible ec2 module` \n\n\u003e This content is derived from terraform...\n\nok: google `pulumi ec2 module`\n\n\u003e The documentation is pretty incomplete\n\n\u003e What would help is better docs - last I checked the docs were not good at all and in a lot of typescript and nodejs. I feel more people who would be doing this would be more comfortable with python and the docs for python were weak. For something like this you need great docs.\n  I know there is a guy in a thread who is tired of ansible but man are the docs pretty good. You can literally google 'ansible \u003cthing\u003e module' and the page comes up. I'll look at it again when the docs are better.\n (reddit: https://www.reddit.com/r/devops/comments/bcdwsn/pulumi/)\n\n\n#### JavaScript! --\u003e Use \"every\" program language you like is currently simple marketing joke\n\nIf you have a look at the docs, you'll soon notice, that the Pulumi JavaScript/Typescript docs are great - but choosing Python already is quite disillusioning. And isn't simply there! And no other language as well.\n\nSimply have a look into the example projects: https://github.com/pulumi/examples and focus on the `language` column\n\nAnd one question: Is it really a good idea to have a full blown programming language available? Do you remember the Design Patterns guys? I once had to integrate a framework, a mathematician build who bought a design pattern book before O_O\n\n__Meme: Mathematician__\n\n\n### Second broken promise: \"Multi-Cloud\"\n\nSee the examples again: https://github.com/pulumi/examples I see AWS, AWS, AWS... an only single Azure, Kubernetes, GCP\n\n\n### Large Community vs Small Community\n\n![comparison-community-common-iac-tools](comparison-community-common-iac-tools.png)\n\n\u003e Ansible leads the pack in terms of popularity\n\n\n\n### Test-driven Development with Pulumi\n\nhttps://www.pulumi.com/blog/testing-your-infrastructure-as-code-with-pulumi/\n\nhttps://www.pulumi.com/blog/tag/testing/ --\u003e 1 article! :(\n\nhttps://www.pulumi.com/blog/unit-testing-infrastructure-in-nodejs-and-mocha/\n\nDiscussion to test harnesses ended in this https://github.com/pulumi/pulumi/issues/1902\n\nThere's a 1 star plugin for [Chef's TDD harness tool kitchenCI](https://kitchen.ci/): https://github.com/jacoblearned/kitchen-pulumi\n\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjonashackt%2Fpulumi-talk","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjonashackt%2Fpulumi-talk","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjonashackt%2Fpulumi-talk/lists"}