<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Terraform on Manuel Bernhardt</title><link>https://manuel.bernhardt.io/tags/terraform/</link><description>Recent content in Terraform on Manuel Bernhardt</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 22 Feb 2025 17:25:54 +0100</lastBuildDate><atom:link href="https://manuel.bernhardt.io/tags/terraform/index.xml" rel="self" type="application/rss+xml"/><item><title>Cloud Run Job with arguments</title><link>https://manuel.bernhardt.io/posts/2025-02-22-cloud-run-job-scheduler-args/</link><pubDate>Sat, 22 Feb 2025 16:10:22 +0200</pubDate><guid>https://manuel.bernhardt.io/posts/2025-02-22-cloud-run-job-scheduler-args/</guid><description>&lt;p>&lt;a href="https://cloud.google.com/run/docs/create-jobs">Cloud Run Jobs&lt;/a> allows to run containers as jobs, i.e. as short-lived tasks that spin up a container every time that they&amp;rsquo;re invoked. As with every container you can use environment variables to pass context. But what if we want to pass arguments to the container?&lt;/p>
&lt;p>In this case, the GCP API specifies &lt;a href="https://cloud.google.com/run/docs/reference/rest/v1/namespaces.jobs/run#ContainerOverride">containerOverrides&lt;/a>. When using terraform, we can pass those with the &lt;code>google_cloud_scheduler_job&lt;/code>resource by customizing the &lt;code>http_target&lt;/code> body like so:&lt;/p></description></item><item><title>On Azure</title><link>https://manuel.bernhardt.io/posts/2024-05-16-on-azure/</link><pubDate>Thu, 16 May 2024 10:49:22 +0100</pubDate><guid>https://manuel.bernhardt.io/posts/2024-05-16-on-azure/</guid><description>&lt;p>&lt;em>I&amp;rsquo;m working with a client &lt;del>condemned to&lt;/del> graced with the privilege of using the Azure Cloud platform. Whilst I have years of experience working with AWS and GCP, my last exposure to Azure goes back to 2017. Memories from that time before Corona are faint, the world was a different place back then. But some things do not change.&lt;/em>&lt;/p>
&lt;h2 id="identities">On Managed Identities&lt;/h2>
&lt;p>&amp;hellip;without having to manage any credentials? The &lt;a href="https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview">sound of it&lt;/a> is pleasant to the ears, and off we go taking this approach to setup an &lt;a href="https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/how-to-connect-with-managed-identity">Azure Database for PosgreSQL - Flexible Server&lt;/a>. The name is long, the process a bit involved, but in the end the identity is there, managed.&lt;/p></description></item><item><title>Migrating from Kubernetes to Google Cloud Run with terraform</title><link>https://manuel.bernhardt.io/posts/2024-03-07-k8s-to-cloud-run/</link><pubDate>Thu, 07 Mar 2024 11:14:12 +0100</pubDate><guid>https://manuel.bernhardt.io/posts/2024-03-07-k8s-to-cloud-run/</guid><description>&lt;p>Kubernetes has its advantages when you&amp;rsquo;re big enough and require the flexibility it offers. But when all you&amp;rsquo;re after is running services and you don&amp;rsquo;t need stateful sets, &lt;a href="https://cloud.google.com/run?hl=en">Google Cloud Run&lt;/a> can be a good alternative (provided you&amp;rsquo;re using Google Cloud Platform). This article provides a few pointers to migrate Kubernetes deployments to Google Cloud Run.&lt;/p>
&lt;h1 id="migrating-yaml-deployment-descriptors">Migrating YAML deployment descriptors&lt;/h1>
&lt;p>There&amp;rsquo;s a &lt;a href="https://cloud.google.com/run/docs/migrate/from-kubernetes">guide for migrating deployment descriptors&lt;/a> which outlines the major syntax differences between a Kubernetes deployment and a Cloud Run service.&lt;/p></description></item></channel></rss>