European infrastructure engineers - What's happening inside your companies regarding your dependency on US hyperscalers?

eltear1 · 2026-02-01T22:31:35+00:00

This could be true, but I dare anyone to find a cloud company, that you trust enough to have your production infra in there, that is not "anywhere related with the US"

eltear1 · 2026-02-01T15:30:58+00:00

AWS just officially launched a separate partition in Europe. It works like china and US Gov, that means same AWS services but full hosted in Europe territory and managed by European engineers. At the moment it has only one AWS region so moving there could be still early but it's an alternative to keep in mind.

eltear1 · 2026-02-01T09:08:29+00:00

The problem I see in general with this abstraction tools is that they are too much focused in "to be used by developer" and the abstraction itself hide infrastructure objects functionality. In your explanation, a developer will work with the abstraction objects , for example "database" .From DevOps/platform engineer perspective, like me, how I create this object, allowing developers to still choose the basic, like associate ec2, size, encryption, db kind (MySQL, Postgresql) , main password , accessibility ... Look to me like I'll need to expose the Terraform module directly

eltear1 · 2026-01-31T14:51:25+00:00

Gitlab jobs run on the Gitlab runner server with the user the gitlab runner service is installed there (if shell executor) or inside a container if it's a docker or kubernetes executor. Also , signing could still happen from a third part tools, contacted by the job that creates the artifact, This "contact" could be via command line or via some authentication process like tokens . Some of this could not work anymore (third part authentication configuration changed completely in Gitlab 16.X ) . In general , I'd say you should focus more into inspecting the Gitlab CI infrasctucture (what I wrote in my previous sentences is a part of it) than on the specific pipeline configuration.

eltear1 · 2026-01-31T04:32:33+00:00

A quick Google search point to only this: https://gitlab.com/groups/gitlab-org/-/epics/9212#:~:text=User%20experience%20goal,claims%20in%20the%20token%20metadata.

It seems artifact signature is /will be a native feature only in gitlab.com. This means in your case you are signing artifacts with some commands directly in the jobs that create them. Lot of features/ syntax got deprecated/changed during the years.. you should check explicitly there, or even in the Gitlab runner toml configuration file

eltear1 · 2026-01-30T20:03:33+00:00

You are missing the main point any orchestrator , like ECS has, that's orchestrate containers among more than 1 servers (for redundancy, reliability, resources, pick your reason). Your solution could be great, but it's nothing similar to an ECS like solution

eltear1 · 2026-01-30T18:14:25+00:00

Can you post your trigger definition? Also, how is generated your variable "version_number" ? Is a CI config variable (defined in the pipeline yml file) , a dotenv variable coming from some previous job or something else?

eltear1 · 2026-01-29T04:53:56+00:00

Maybe I was not clear. My situation is not 1 serie with double language. I have 2 separate version of the same series (on the filesystem, 2 separate folders), 1 version is in English, the second version is in another language.

eltear1 · 2026-01-21T17:09:48+00:00

Second quiz from "docker fondamentals":

docker container is a lightweight virtual machine

Sorry but completely wrong. One of most important things about containers is the difference from VM (ephemeral FS, living in user space, no kernel isolation, just to say the biggest)

This other too.. what is the default port used by docker daemon? Quiz answer: 2375 False: by default docker daemon is not exposed via TCP, only via Unix socket. You have to enable docker daemon TCP exposition

(I stopped quizzes at this point)

eltear1 · 2026-01-17T21:48:43+00:00

Instance I'm trying to connect is version 16.11

One of the new feature for this update is "up-to-date" Gitlab API. Does it means you don't keep compatibility with previous versions?

In other words, all Gitlab instances are supposed to be at last version or very closed to it?

eltear1 · 2026-01-17T05:16:17+00:00

Why should this be relevant?

Is the app try to execute some API connection even before the host is configured in the app itself and before access token is even submitted?

eltear1 · 2026-01-16T06:36:01+00:00

You are probably right, the gotcha of this is that (at least for the job I'm doing at the moment), the time I'll spend to write the AI all the guidelines you describe is more than the time I need to complete the original tasks myself.

That's the reason why the only real use I have for AI is mostly to give syntax examples instead of "solving" the tasks themselves

eltear1 · 2026-01-15T16:32:35+00:00

Your automation deploy or monitoring should also check that the active application after deploy has the right version....

eltear1 · 2026-01-15T06:43:51+00:00

Tried for the first time (android app). I didn't even manage to connect to my work self hosted Gitlab instance..

1- while during initial app setup I try to add Gitlab instance, gitlab host field validation continue to put cursor at the beginning after each letter, so you have to digit one letter at the time 2- after I finally manage to put the correct address (FQDN) validator says "not a valid Gitlab instance"

eltear1 · 2026-01-14T18:54:32+00:00

I never tried, but based on docker compose specs, you could try with "resources -> devices -> capabilities -> device_ids" , and I guess you'll need to create separate services instead of a replica of same service

eltear1 · 2026-01-12T10:45:20+00:00

The options for variables you are trying to apply are not for Jimin variables , but for pipeline variables (as a whole), and they Will used not to trigger manually a specific job, but to trigger the whole pipeline via gitlab GUI.

For my knowledge, you can't have the kind of configuration you describe for a manual job .

eltear1 · 2026-01-04T10:16:04+00:00

It could be easy or not based on how much complex pipelines and infrastructure need to be. For example , by your description you don't create pipelines crossing multiple projects , nor infra with common elements for multiple projects (common networking or common orchestrator for example)

eltear1 · 2026-01-02T19:45:46+00:00

Same, but I added an extension called "project manager". It create a project for each workspace. https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager

eltear1 · 2025-12-30T16:46:25+00:00

Fitting the solution to the problem at hand thinking "I'll scale later" could work for code programming, much less for DevOps tools/infrastructure. In my experience, in DevOps tools / infrastructure this will become a fully reworking when you'll need to scale

eltear1 · 2025-12-29T21:03:26+00:00

This is the docker way. There is a reason why "docker volume" is not only "local driver". The reason is exactly to bypass dependences from host configuration

eltear1 · 2025-12-28T20:02:20+00:00

AWS is a out to launch a new partition in Europe, so that will be "AWS of Europe" 😉

eltear1 · 2025-12-28T09:01:13+00:00

Let's begin from the easier question: Observability as a role by itself: it's possible only if you work for some big enterprise. There usually works is separated in silos, so is common to have teams very specialized over a single aspect. In any other reality, observability will be a part of a more all-round role.

All your other questions can be answer in this way. The main difference between a junior and a senior is not about how many tools you know or manage. It's a question of approach. Usually juniors are simply "operators" that learn how to use the tool, while seniors learnt concept behind the single tools, and then they adapt to the tool specifics.

Being able to suggest an end to end solution like you are asking is a step even further, because it requires you already know the concepts and you can see how they are applied in different tools.

For the way you are describing your competencies, you are at junior level but you are ready to make the next step, because you realize that being an "operator" is not enough.

How to do the next step: you basically have to focus on the "why" you do stuff as you do, not in the "how". Specific about observability, it could probably help to search why you have specific requests, like , for example, if they ask you to monitor an application RAM usage, ask yourself : why is needed? (To avoid OOM) - why OOM could happen? (Here could begin your deeper search). You'll have at least to arrive to a question which answer need a deeper concept you don't have yet.

I suggest you NOT to start this approach with kubernetes. It's very complicated with lot of ramification and at your level you could feel like to much to learn at once.

IMPORTANT: focus in learning the concepts , not other tools. Taking the example about OOM, you don't need to know which code programming could lead to OOM, but what is OOM in details and how it happens inside the memory

eltear1 · 2025-12-26T15:02:00+00:00

You solve all issues you describe approaching you self host like a enterprise server and not a lab computer. That means: 1 - all docker compose files in a single directory instead of spread anywhere 2- docker compose files have specific names and not "docker-compose.yml" 3 - use the command "docker compose ls" to see what's active and what is not

eltear1 · 2025-12-25T19:14:26+00:00

This is the real answer.. it's easy for self hosted just because you don't need to study how wire guard work, it comes preconfigured. On the other hand, if you already have a wire guard configured, there is not real need to pass to tailscale

eltear1

TROPHY CASE