feat: build windows containers

[sumo-drosiek]

Adds building windows containers. This PR uses docker command in order to build manifest, as for some reason docker buildx was not always working, also buildx is not supported on windows

➜  ~ docker manifest inspect public.ecr.aws/sumologic/sumologic-otel-collector-dev:latest
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1093,
         "digest": "sha256:1fde89d7412f56cac8e295ec067895780d36755c1e0c442e2832024c54b09d4f",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1093,
         "digest": "sha256:5815d396401f4f24d69d90c7df4b918c030212719178d368d7d25ccda1b4fbb8",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1788,
         "digest": "sha256:79230acc35c7a076a9eab9e851839971a6f43c74d4ef184811962f1904ac5f2c",
         "platform": {
            "architecture": "amd64",
            "os": "windows",
            "os.version": "10.0.17763.5458"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1788,
         "digest": "sha256:711ab12580c5d2c1bd18785be0e9e675b62d6df01bf13d5c22793d567f0c71a3",
         "platform": {
            "architecture": "amd64",
            "os": "windows",
            "os.version": "10.0.20348.2322"
         }
      }
   ]
}

[swiatekm]

Do we have to rely on this?

[sumo-drosiek]

So, this is complicated. We cannot use nanoserver as it doesn't provide Netapi32.dll link

Also it means for windows what are the base image and what system we try to run it on. Manifest should have addition os.version field, and ideally we should provide multiple windows images. Not sure if newer windows can run older images, as github actions had issues with running image based on older tag.

Due to above, I'm not sure if this should be run for release branches, as those are still experimental images

[sumo-drosiek]

➜  ~ docker manifest inspect public.ecr.aws/sumologic/sumologic-otel-collector-dev:0fa281c6c04691e937f403218b09de6e91f04d29
{
   "schemaVersion": 2,
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1093,
         "digest": "sha256:719c9ffed95ff6eda12c6564e70c1c025352dacb376f5dfc01a37cdc87f6953d",
         "platform": {
            "architecture": "amd64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1093,
         "digest": "sha256:8a04067bc357fee33f1e11b468e408ed26950f0ea7382d47ccc6b3614f2150d9",
         "platform": {
            "architecture": "arm64",
            "os": "linux"
         }
      },
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 1788,
         "digest": "sha256:914c7d0ee0927e2d065f6b74f03ab036e9758afa76cb09d54cf99340dbb9609b",
         "platform": {
            "architecture": "amd64",
            "os": "windows",
            "os.version": "10.0.20348.2322"
         }
      }
   ]
}

Working on building multitple images, as this one is not working on my eks windows cluster 😅

[swiatekm]

🙉 Yeah, let's start with just dev builds then. This PR overall looks a bit messy and I think we should try to consolidate our image building logic a bit more. So it'd be better to just do it for dev images, then clean up a bit, figure out the edge cases and then start building release images.

[swiatekm]

Why do we need to do this?

[sumo-drosiek]

To verify if we have connection with docker server

[swiatekm]

Is this actually necessary in practice? Do we get into situations where we try to build and the docker daemon hasn't started yet?

[sumo-drosiek]

not really as it will fail further in the pipeline eventually

[rnishtala-sumo]

Have we tried downloading the unattended installation of the buildx component from here?, looks like there are windows executables

https://github.com/docker/buildx?tab=readme-ov-file#manual-download

Binaries from the github release page
https://github.com/docker/buildx/releases/tag/v0.12.1

got the above from this comment

[rnishtala-sumo]

oh nvm, looks like this is the root cause - docker/buildx#176, buildx on windows containers not supported.

[sumo-drosiek]

Hmm, maybe it is suppored, but I would prefer to have more control over what happening with windows image builds and also avoid experimenting support. I would feel more comfortable to switch to it when it will be fully supported, or maybe if we go for FIPS/arm64