Migrate individual container images to scale owned registry

[sarcasticadmin]

Description

Relates to: #286

Originally raised up in: https://github.com/socallinuxexpo/scale-network/pull/413#discussion_r782378384

There are a container images that we currently have for CI that are hosted in individual contributor owned container registries. It would be easier to centralize these so that we could better integrate them with CI and allow of other team members to contribute to them. Examples of such images:

• openwrt build: https://github.com/socallinuxexpo/scale-network/blob/3282e9a/.github/workflows/openwrt-build.yml#L16
• ansible test: https://github.com/socallinuxexpo/scale-network/blob/3282e9/.circleci/config.yml#L80

We really should have a socallinuxexpo branded registry to push to.

Acceptance Criteria

• Identify the appropriate registry to sign up for (Dockerhub, etc.)
• Create a socallinuxexpo toplevel org
• Migrate existing images to utilize new registry

[kylerisse]

Docker hub is probably the way to go? Would be up to @irabinovitch . Since we're leveraging docker quite a bit now for CI and keeping the rusty PHP 5.4 signs code base going, would probably be worth a Pro account subscription in the name of socallinuxexpo now that Free accounts get inactive images removed automatically.

This also applies to

• https://github.com/socallinuxexpo/scale-network/blob/ffda5117e0fd7757dbf4d43f190f13f5092b0254/nix/machines/signs.nix#L21 Also, since moving to GHA, the new links for the above are:
• https://github.com/socallinuxexpo/scale-network/blob/ffda5117e0fd7757dbf4d43f190f13f5092b0254/.github/workflows/ansible-test.yml#L26
• https://github.com/socallinuxexpo/scale-network/blob/ffda5117e0fd7757dbf4d43f190f13f5092b0254/.github/workflows/ansible-test.yml#L39
• https://github.com/socallinuxexpo/scale-network/blob/ffda5117e0fd7757dbf4d43f190f13f5092b0254/.github/workflows/openwrt-build.yml#L18

Also note, the two ansible-tester images might not be needed now that we're on NixOS. We will need to peel the data validation portions of that workflow out, but that should just require basic python.

[kylerisse]

Creating an organization for this on Docker Hub is probably not the way to go, given their recent policy changes. Perhaps GitHub’s Container Registry is an option.

[sarcasticadmin]

Thanks for the call out of each of the container refs @kylerisse

Also note, the two ansible-tester images might not be needed now that we're on NixOS. We will need to peel the data validation portions of that workflow out, but that should just require basic python.

Agreed

Creating an organization for this on Docker Hub is probably not the way to go, given their recent policy changes. Perhaps GitHub’s Container Registry is an option.

I need to brush up on the changes, but Im definitely in for dig into the githubs registry and see how well it fits for our needs.

[kylerisse]

Interesting timing, the organization changes was top post on Hacker News today: https://news.ycombinator.com/item?id=35166317

[davidelang]

(soapbox mode=on)

this is why you can't count on Internet hosted things when running your network, you need to have a local copy of the repos(source or package)/images that you count on.

Things on the Internet move and disappear, and they have also had content (including code) changes with no notice or warning, even for older versions of code.

Too many companies don't understand this until they get bit by a change.

(soapbox mode=off)

David Lang

On Wed, 15 Mar 2023, kylerisse wrote:

Interesting timing, the organization changes was top post on Hacker News today: https://news.ycombinator.com/item?id=35166317

[kylerisse]

@davidelang you're preaching to the choir!

I agree and believe quite a few companies will be learning this over the next 30 days.

For us, we have simple needs, can regenerate from source, and support a short term, transitory environment. I just don't think we need to pay Docker given our small footprint.

[owendelong]

AIUI, NIX allows us to essentially specify container contents via code (text). (I fully admit, I may completely misunderstand)

Can we manage those containers as code and migrate what we’re currently doing with Docker to NIX?

In that way, couldn’t we just keep all the spec’s in our GIT repo and not need a specialty storage for container images?

(I’m still in favor of migrating our repo to GITLAB or BITBUCKET because: delong-dhcp155:owen (119) ~/Downloads/confluence_faradayfuture_com % host gitlab.com 2023/04/20 10:17:22 gitlab.com has address 172.65.251.78 gitlab.com has IPv6 address 2606:4700:90:0:f22e:fbec:5bed:a9b9 gitlab.com mail is handled by 1 aspmx.l.google.com. gitlab.com mail is handled by 5 alt1.aspmx.l.google.com. gitlab.com mail is handled by 5 alt2.aspmx.l.google.com. gitlab.com mail is handled by 10 alt3.aspmx.l.google.com. gitlab.com mail is handled by 10 alt4.aspmx.l.google.com. 0.001u 0.013s 0:00.58 1.7% 0+0k 0+0io 43pf+0w delong-dhcp155:owen (120) ~/Downloads/confluence_faradayfuture_com % host bitbucket.com 2023/04/25 9:36:12 bitbucket.com has address 18.205.93.5 bitbucket.com has address 18.205.93.3 bitbucket.com has address 18.205.93.4 bitbucket.com has IPv6 address 2406:da00:ff00::12d0:47c8 bitbucket.com has IPv6 address 2406:da00:ff00::22ed:a9a3 bitbucket.com has IPv6 address 2406:da00:ff00::12cc:b432 bitbucket.com mail is handled by 10 mxa-001d9801.gslb.pphosted.com. bitbucket.com mail is handled by 10 mxb-001d9801.gslb.pphosted.com. 0.002u 0.005s 0:00.39 0.0% 0+0k 0+0io 6pf+0w delong-dhcp155:owen (121) ~/Downloads/confluence_faradayfuture_com % host github.com 2023/04/25 9:36:16 github.com has address 140.82.112.3 github.com mail is handled by 1 aspmx.l.google.com. github.com mail is handled by 5 alt1.aspmx.l.google.com. github.com mail is handled by 5 alt2.aspmx.l.google.com. github.com mail is handled by 10 alt3.aspmx.l.google.com. github.com mail is handled by 10 alt4.aspmx.l.google.com. )

Owen

On Mar 15, 2023, at 14:16, kylerisse @.***> wrote:

@davidelang https://github.com/davidelang you're preaching to the choir!

I agree and believe quite a few companies will be learning this over the next 30 days.

For us, we have simple needs, can regenerate from source, and support a short term, transitory environment. I just don't think we need to pay Docker given our small footprint.

— Reply to this email directly, view it on GitHub https://github.com/socallinuxexpo/scale-network/issues/418#issuecomment-1470855429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK6GTRRDCYHYY5QIBNNWZ3W4IWUTANCNFSM5LYBEYLA. You are receiving this because you are subscribed to this thread.

[davidelang]

that would require that we build the docker images from scratch every time we wanted to deploy them.

having a registry that's populated by the code at checkin (with history available) gives us the ability to just grab an image and run it.

The registry is also a good place to have the image audited

at least as I understand it

David Lang

On Tue, 25 Apr 2023, Owen DeLong wrote:

Date: Tue, 25 Apr 2023 09:37:15 -0700 From: Owen DeLong @.> Reply-To: socallinuxexpo/scale-network @.> To: socallinuxexpo/scale-network @.> Cc: David Lang @.>, Mention @.***> Subject: Re: [socallinuxexpo/scale-network] Migrate individual container images to scale owned registry (Issue #418)

AIUI, NIX allows us to essentially specify container contents via code (text). (I fully admit, I may completely misunderstand)

Can we manage those containers as code and migrate what we’re currently doing with Docker to NIX?

In that way, couldn’t we just keep all the spec’s in our GIT repo and not need a specialty storage for container images?

(I’m still in favor of migrating our repo to GITLAB or BITBUCKET because: delong-dhcp155:owen (119) ~/Downloads/confluence_faradayfuture_com % host gitlab.com 2023/04/20 10:17:22 gitlab.com has address 172.65.251.78 gitlab.com has IPv6 address 2606:4700:90:0:f22e:fbec:5bed:a9b9 gitlab.com mail is handled by 1 aspmx.l.google.com. gitlab.com mail is handled by 5 alt1.aspmx.l.google.com. gitlab.com mail is handled by 5 alt2.aspmx.l.google.com. gitlab.com mail is handled by 10 alt3.aspmx.l.google.com. gitlab.com mail is handled by 10 alt4.aspmx.l.google.com. 0.001u 0.013s 0:00.58 1.7% 0+0k 0+0io 43pf+0w delong-dhcp155:owen (120) ~/Downloads/confluence_faradayfuture_com % host bitbucket.com 2023/04/25 9:36:12 bitbucket.com has address 18.205.93.5 bitbucket.com has address 18.205.93.3 bitbucket.com has address 18.205.93.4 bitbucket.com has IPv6 address 2406:da00:ff00::12d0:47c8 bitbucket.com has IPv6 address 2406:da00:ff00::22ed:a9a3 bitbucket.com has IPv6 address 2406:da00:ff00::12cc:b432 bitbucket.com mail is handled by 10 mxa-001d9801.gslb.pphosted.com. bitbucket.com mail is handled by 10 mxb-001d9801.gslb.pphosted.com. 0.002u 0.005s 0:00.39 0.0% 0+0k 0+0io 6pf+0w delong-dhcp155:owen (121) ~/Downloads/confluence_faradayfuture_com % host github.com 2023/04/25 9:36:16 github.com has address 140.82.112.3 github.com mail is handled by 1 aspmx.l.google.com. github.com mail is handled by 5 alt1.aspmx.l.google.com. github.com mail is handled by 5 alt2.aspmx.l.google.com. github.com mail is handled by 10 alt3.aspmx.l.google.com. github.com mail is handled by 10 alt4.aspmx.l.google.com. )

Owen

On Mar 15, 2023, at 14:16, kylerisse @.***> wrote:

@davidelang https://github.com/davidelang you're preaching to the choir!

I agree and believe quite a few companies will be learning this over the next 30 days.

For us, we have simple needs, can regenerate from source, and support a short term, transitory environment. I just don't think we need to pay Docker given our small footprint.

— Reply to this email directly, view it on GitHub https://github.com/socallinuxexpo/scale-network/issues/418#issuecomment-1470855429, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK6GTRRDCYHYY5QIBNNWZ3W4IWUTANCNFSM5LYBEYLA. You are receiving this because you are subscribed to this thread.

[sarcasticadmin]

@owendelong

AIUI, NIX allows us to essentially specify container contents via code (text). (I fully admit, I may completely misunderstand)

Definitely, we have the ability to build containers using nix and its dockerTools set of functions (https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/docker/default.nix)

Can we manage those containers as code and migrate what we’re currently doing with Docker to NIX?

In that way, couldn’t we just keep all the spec’s in our GIT repo and not need a specialty storage for container images?

Yes we could do that and we probably would do that going forward if we needed containers.

However, to echo @kylerisse other comments earlier in the thread, I really dont think we need the containers we have.

• ansible-tester - Most of this can be done via nix. We were largely using the container for consistency for the packages.
• scale-signs - Again were largely using the container for consistency for the packages, even if we have to use it "as-is" we can get the correct packages on the vm directly via nix now.
• scale-openwrt - Ditto for this as well

that would require that we build the docker images from scratch every time we wanted to deploy them.

@davidelang not necessarily, nix keeps a local cache /nix/store for anything it builds to subsequent builds dont have to start from nothing. This includes things like containers when building with nix. But again to the points made above, I dont think we need any of the containers we current have long term.

[nixinator]

If you can get this working, this is ultra cool and fully 'dialled in'.

[sarcasticadmin]

Closing in favor of https://github.com/socallinuxexpo/scale-network/issues/627