pritunl-k8s-tf-do VS argo

I have a full example here of a working GHA pipeline that deploys terraform infrastructure. This deploys atlantis, which can then be used to deploy Pritunl VPN. Works almost perfectly except for the fact that helm yaml encoded sensitive values are revealed on terraform destroy, so I simply don't have anything sensitive encoded in yaml.

Hey now, I've already got a homelab that launches a k8s cluster and installs Pritunl VPN for coffee shop wifi. I do at least understand that tools need a valid use case before being applied, although admittedly installing it on k8s vs just using Nomad or something is more RDD than not for this one.

I'm looking for a company that is willing to judge me based off of past experience and previous projects I've already completed. So ideally no LeetCode, and no more take homes unless you want me to post them publicly. Ideally looking to come in at $160K+ for mid level or $200K+ for senior, depending on how much of a match there is between me and the position, and a sign-on bonus would be incredible. Hopefully I have enough of a reputation at this point where you've seen my posts and comments in /r/devops and already know what I'm capable of, but if not, I'm happy to chat about previous projects in-depth and go over what I've worked on. A code review as part of the interview process would be absolutely stellar. This is what I've been working on recently as well as my "homelab" if you re looking for some specifics. DM or chat with your work email for an official resume

Already done, but good call on learning how to create conditionals. I will look into it!

Playing around with grafana/loki/prometheus all via Terraform, GitHub Actions, and Atlantis in a public repo.

I set up a whole pipeline to install and configure Pritunl VPN on DigitalOcean and it only costs me like $60/month for a 3 node cluster.

https://github.com/autotune/pritunl-k8s-tf-do/blob/master/README.md is the repo. The README should answer any questions about how the pipeline works but the end result is a pritunl webgui listening on port 80 with an ingress route for https, a SERVICE load balancer that listens for VPN connections, and the ability to connect to said service load balancer over Pritunl VPN client. Note this is missing a few things, for one you can only have a replica set of 1 in the deployment. I need to figure out how to add HA with the "enterprise" edition at $70/month extra (still relatively cheap for what you get!). But for personal use it should suffice. Also, I tried using an ingress for the vpn itself but can't get it working, so stuck with SVC load balaner instead, which works fine. Any suggestions here would be appreciated!

All I know for sure is the one cert I was using with letsencrypt kept failing to renew. I just tried it with zerossl since the sign up page cert was finally renewed last night and people have generally been happy with them outside this little incident and seems to actually be working as expected. The helm release I am using is linked to via tf here and the ingress rules are here.

Like Argo Workflows?

https://github.com/argoproj/argo-workflows

Dagger looks more comparable to Argo Workflows: https://argoproj.github.io/argo-workflows/ That's the first of the Argo projects, which can run multi-step workflows within containers on Kubernetes.

For what it's worth, my colleagues and I have had great luck with Argo Workflows and wrote up a blog post about some of its advantages a few years ago: https://www.interline.io/blog/scaling-openstreetmap-data-wor...

Despite other alternatives like Circle CI, Travis CI, GitLab CI or even self-hosted options using open-source projects like Tekton or Argo Workflow, the reason for choosing GitHub Actions was straightforward: GitHub Actions, in conjunction with the GitHub ecosystem, offers a user-friendly experience and access to a rich software marketplace.

author seems to be describing the kind of patterns you might make with https://argoproj.github.io/argo-workflows/ . or see for example https://github.com/couler-proj/couler , which is an sdk for describing tasks that may be submitted to different workflow engines on the backend.

it's a little confusing to me that the author seems to object to "pipelines" and then equate them with messaging-queues. for me at least, "pipeline" vs "workflow-engine" vs "scheduler" are all basically synonyms in this context. those things may or may not be implemented with a message-queue for persistence, but the persistence layer itself is usually below the level of abstraction that $current_problem is really concerned with. like the author says, eventually you have to track state/timestamps/logs, but you get that from the beginning if you start with a workflow engine.

i agree with author that message-queues should not be a knee-jerk response to most problems because the LoE for edge-cases/observability/monitoring is huge. (maybe reach for a queue only if you may actually overwhelm whatever the "scheduler" can handle.) but don't build the scheduler from scratch either.. use argowf, kubeflow, or a more opinionated framework like airflow, mlflow, databricks, aws lamda or step-functions. all/any of these should have config or api that's robust enough to express rate-limit/retry stuff. almost any of these choices has better observability out-of-the-box than you can easily get from a queue. but most importantly.. they provide idioms for handling failure that data-science folks and junior devs can work with. the right way to structure code is just much more clear and things like structuring messages/events, subclassing workers, repeating/retrying tasks, is just harder to mess up.

Argo Workflows + Argo Events

Drone, or Tekton, Argo Workflows if you’re on k8s

Check out Argo Workflows.

go-git has a lot of bugs and is not actively maintained. The bug even affects Argo Workflow, which caused our data pipeline to fail unexpectedly (reference: https://github.com/argoproj/argo-workflows/issues/10091)