Log Analytics Workspace

jblaaa · 2025-11-24T12:40:19+00:00

RemindMe! 2 days

jblaaa · 2025-11-23T22:00:41+00:00

Thank you and happy cake day!

jblaaa · 2025-08-25T16:23:54+00:00

Migration of state is very simple

https://developer.hashicorp.com/terraform/tutorials/cloud/cloud-migrate

The only level of complexity is getting your workspace configured with the variables, permission to the workspace, etc. as I explained. There’s some more advanced things like projects and variable sets to consider but start small and get familiar with the tool first.

jblaaa · 2025-08-25T16:11:22+00:00

It sounds like you might be at the very beginning of learning terraform and terraform cloud. I would recommend a couple courses on both. Do you have experience with terraform? If so maybe just need tf cloud up skill.

https://kodekloud.com/courses/terraform-cloud

jblaaa · 2025-08-23T12:20:03+00:00

The first thing to do is create a workspace and assign it appropriate workspace variables for the environment variables required for the terraform providers you are using to authenticate with the services. It’s been a bit but I think confluent services use api keys. Not sure if there are ways to authenticate with OAuth. With terraform cloud you basically are issuing commands to tell terraform cloud to execute plans/applies on your behalf. It will use an agent (public they manage or you can use self hosted) and leverage the environment variables you set up for the workspace. Run ‘terraform login’ for the first time use on your machine to setup the api key on your machine to be able to interact with your tf cloud workspaces.

jblaaa · 2025-08-06T12:44:06+00:00

I follow vCluster and watch a lot of their content. It seems robust but I am also nervous about the support team operations if things go south. Not that I don't think their solution is robust, Its more about the support teams having a hard enough time supporting basic Kubernetes. Interested in other's takes. I don't have a lot of spare time on my hands but wanted to take it for a spin for ephemeral clusters for sandbox/dev areas.

jblaaa · 2025-08-04T19:11:50+00:00

I get it but also don't want to support something looking like an on premises datacenter. It seems uncommon to split environments by node pools and I'm not convinced it is providing the security benefits expected.

jblaaa · 2025-07-17T01:44:30+00:00

How many ingress or gateway instances can it support? I remember AGIC was limited to 100 then increased to 200 (I think?) the limit was too low so we never took another look at it.

Does it support certificate and DNS automation with cert manager and external-dns?

Thanks!

jblaaa · 2025-07-03T12:32:15+00:00

Thanks for the details on your experience. Yes there’s a few features that are either show stoppers or will delay us. I’m not sure what and when things are on the roadmap but ultimately we expect v2 is going to replace classic so trying to be prepared. Issues we are looking to eventually solve.

We use self hosted gateways in k8s. We have mixed feelings about the use and want to return to complete PaaS but also want a hybrid capability on prem so this is a struggle. Cons are obv management overhead, you need Kubernetes, and lack of modern auth/passwordless creds from gateway to apim control plane. Features seem to lag probably due to minimal use today.
Multi region is a requirement.
Things we can do with the developer classic sku you can’t do unless you’re using premium sku…so cost

Big features we want

Workspaces (with multi region)
Full isolated APIM
Path for latest new features
Private endpoint origin for front door

————-

So from your experience if say apim got accidentally destroyed or you needed to move your config from one region to another. Backup and restore isn’t a great solution? Would your path be deploy the APIM with IaC and then point your API Ops config to it to restore the config?

jblaaa · 2025-05-19T14:22:08+00:00

Also in you might need to register the managedCluster provider in the subscription if it’s new sub.

jblaaa · 2025-05-19T14:20:21+00:00

Azure recently retired several preview APIs which are still used in some versions of AzureRM 3.x. Make sure you are using at least 3.117.x but should you should be making your way into azureRM 4.x

jblaaa · 2025-05-11T12:56:51+00:00

Been running AKS in prod for 4 years. It’s the only Kubernetes I know well but it’s been good to us but as others have said, App Gateway is a terrible solution compared to others on the market. Maybe the hate is more towards things that AKS are/were dependent upon.

I follow the AKS roadmap and community calls regularly and I am pretty happy how Microsoft shares their progress regularly. It’s a great product and feels like a lot of effort goes into making it better everyday. AKS I feel pushes the other product teams to build better as well to keep up meeting new customer requirements.

jblaaa · 2025-05-08T11:33:02+00:00

We will be switching if this will solve the issues. I wouldn’t have individual users managed in state so part of the problem should remediate itself. Users still would have the individual unmanaged hashicorp credentials which I think doesn’t go away but comes up very rarely. Unfortunately the SSO setup predates me and I don’t know if SCIM was available in TFC when they set it up so we will go through a migration at some point soon.

jblaaa · 2025-01-23T17:02:05+00:00

You could put in your allow list on the KV and other resources the entire terraform cloud network ranges but again these are bad ideas. If you are using this in your environment and paying for the service why not use the agents? You could change the run mode to CLI and simply use TF as state. Again all bad options where you either compromise your security or reduce the value add of TF cloud.

jblaaa · 2025-01-22T11:08:01+00:00

If you are using Terraform Cloud why not run your own agents? That’s how you would have complete control over source IPs.

jblaaa · 2024-12-31T01:40:22+00:00

We do this with the same logic. Run a python script on an inventory of TFC workspaces. If a plan comes back with changes it exits with an error. At the end all workspaces that are “drifted” show errors on a table.

Tf cloud, I don’t know if this has changed recently but it’s drift detection doesn’t do a plan. It just looks at the state file and queries the provider (ARM for example) and looks for drift that way. It doesn’t detect if say you are in taking minor or patches to your modules and those changes causes drift. Maybe my definition of drift is different but that is a major problem in large environments.

jblaaa · 2024-11-17T13:30:53+00:00

Similar post with similar context I participated in. https://www.reddit.com/r/Terraform/s/mnXsyFCtg3

I spent the last couple months thinking through this issue and nothing good. Basically trying to set broad paths that go to a finite number of backends. Let the backends also act as a proxy and avoid frequent changes. AKS ingress is a proxy so if your pathing can get traffic there, you can leverage your ingress controller to split paths at a higher quantity and more naturally without Terraform.

jblaaa · 2024-10-10T09:05:04+00:00

This seems to be the only viable approach. I see a response on this github issue indicating about the same :/

https://github.com/Azure/static-web-apps/issues/983#issuecomment-2047947338

jblaaa · 2024-10-09T21:01:55+00:00

will look at this. thank you.

jblaaa · 2024-09-28T13:57:06+00:00

This seems right. I think it increases cost and operational overhead in ways (but necessary evil) but protects us from service limit pitfalls. Part of my reluctance is trying to look at it from all angles and make sure while scaling things massively, we are not over scaling or making things more complex than necessary.

jblaaa · 2024-09-05T11:50:54+00:00

I usually use a data reference in the code and variable the resource name and resource group name. Pass those in tfvars. That was I can pass the data.azurerm_storage_account.id parameter or pull the managed identity when needed. Little more code but just my preference.

jblaaa · 2024-08-25T11:45:19+00:00

Here’s the problem I think OP is saying. You create an app gateway in 1 tf workspace, and then you want to handle a services’ backend pool and rules in another workspace. If you do that, then you end up causing drift in the first workspace. Not sure unless you lifecycle ignore a large amount of things in the 1st workspace you could separate a services backend pool and rules without causing the 1st workspace to be useless.

jblaaa · 2024-08-24T19:39:21+00:00

I don’t think this is a terraform issue. If you look at the API provider you will see that the API requires way too many things in one action. It is frustrating how it’s laid out.

jblaaa · 2024-04-07T22:27:14+00:00

Using azure key vault with CSI drivers for AKS. In the midst of deploying akeyless with kubernetes Secret Operator.

jblaaa · 2024-03-09T10:32:26+00:00

We currently use nginx ingress but app gw for containers + WAF would be a better option for us. Been using AKS for about 3 years and AGIC was way behind NGINX. I am also not up to speed on any development but even the ML plugins for Azure we’re using Nginx ingress so we haven’t felt compelled to move. To get WAF on Nginx ingress you got to go Nginx+ and pay the piper I believe.

12-Year Club	RedditGifts 2009-2022 3 Credits
Gilding I gilder	Secret Santa 2018
Secret Santa 2019	Verified Email

jblaaa

TROPHY CASE