#humanitec — Public Fediverse posts

Putting new #robotframework #humanitec library in to action.

Deploy multiple containers with #score through a robot task in a #gitlab ci.

I generated a #humanitec client in #python from the official #openapi spec (version 0.24.1). It required fixing as the specification was incomplete and #swagger-codegen has a bugs in its python generator. I am unsure about the feasibility, but will maintain this #gitlab project for now.

If you are into #platformengineering and #devops and you like to orchestrate your #platformorchestrator with Python, you may try this #opensource client.
https://gitlab.com/noordsestern/unofficial-humanitec-client

So after my barely entertaining attempt to deploy #zeebe playground with #score on #humanitec the other day, I received a workaround how to deploy several workload defined in score. 🙏

The code snippet inspired me to use #robotframework instead of shell script.

After a day forcing #swagger-codegen to create an acceptable #python client from #openapi spec, I ended up releasing a small alpha: robotframewor-humanitec 🎉

Available as #OpenSource on pypi.org: https://pypi.org/project/robotframework-humanitec/

I tried streaming on twitch last night. Deploy #zeebe and #zeebe-monitor with #score on #humanitec. It was a tech-check for audio and video and in that regard, it worked.

However, it is very boring to watch. When something does not work, I am so much in my thoughts without saying anything. Watching me scrolling through documentation, trying different variations of gitlab pipelines.

Will need more practice for being more expressive when I am on my own.

With the help of #mustache templates you can create #score specifications for cronjobs that run at times with the least amount of carbon emissions. This example shows a step by steop guide using the carbon aware computing API by #bluehands deploying the cronjob to #humanitec

#greenit #opensource
https://noordsestern.medium.com/carbon-optimized-cronjobs-in-score-5838d07aab42?source=rss-423c4993415------2

My latest blog post - Platform engineers!! Here are 8 must-have tools:

1. #Docker - To containerize your applications
2. #Kubernetes - For container orchestration
3. #Terraform - To automate infrastructure provisioning
4. #Crossplane - For cloud native infrastructure management
5. #GitHub - For Continuous Integration
6. #ArgoCD - For your Continuous Deployment
7. #Backstage - For your IDP
8. #Humanitec - For your IDP

Read it here:

https://www.pluralsight.com/resources/blog/it-ops/top-platform-engineering-tools

I tried #score from https://score.dev and quite like it.

I miss an option to parameterize specifications. Luckily, #Mustache templates work for everything. Here is an example how to template #score-spec with #chevron (#python implementation of mustache)

https://noordsestern.medium.com/using-mustache-for-parameterizing-score-definitions-d5153a72fed0

#unofficial #humanitec #kubernetes #opensource

Deploying #camunda with #humanitec

https://medium.com/@noordsestern/part-3-deploy-camunda-7-with-humanitec-52cf12580689

My own project trying out Humanitec gets bigger - and requires a process orchestrator. So I looked in to deploying my favorite. Luckily it was even easier than I had expected.

In order to learn the benefits of #internaldeveloperplatform I started using #humanitec for my own little project.

Since I prefer #gitlab I connected my gitlab #ci and container registry with Humanitec in order to deploy custom images as workload.

Here is a little summary in form of a #howto : https://noordsestern.medium.com/part-2-connect-your-gitlab-registry-with-humanitec-240efecf4f01

#platformengineering #idp #k8s

Since weeks, I have a #robotframework service provisioned with #humanitec on a #k8s cluster - and every 2 days I have to redeploy the service. From logs it looked like playwright was eating memory. Thought about scheduling redeployments, improving load-balancing.

In the end turned out to be simple: one of the tasks did not call CLOSE BROWSER thus the browser instances remained as zombies and waited for the main thread (= the service) to end.

As a software developer who "just wants things to work" the concept of #platformengineering and internal developer platforms (#idp) were hard to grasp before I joined #Humanitec

Despite learning the tool inside out I need to try it out myself in order to truely understand.

So I started to use #humanitec privately. As lonely #developer who spend his sparetime writing littls apps that need to run on cloud.

I share my personal experience on my blog:

https://noordsestern.medium.com/start-playing-with-humanitec-db8e04de3fca

Finally playing around with my own #civo #k8s cluster managed by #humanitec

Deployed #camunda #zeebe with #zeebe-monitor. Just worked.

Deployed #robotframework-webservice as virtual tester. Just worked.

And despite #humanitec is supposed to hide all k8s-fuzz from me, i still learned something about #traefik ingress.

I suppose now is a good time to go to bed.

#platformengineering

We (#ITQ) started our cloud-native consultancy practice around our partnership with #Pivotal, so we have been helping customers set up platform-teams to do 'platform engineering' for 5 years now.

But the recent trend (I mean of the last year) of talking about 'platform engineering' seems to at least be partially due to #Humanitec throwing out whitepaper after whitepaper, including sponsored posts at The New Stack, about this.

(1/2)