Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Unregistry – “docker push” directly to servers without a registry

github.com

Post reply on HN
Print view View original

101–110 of 178 posts

Re: Show HN: Unregistry – “docker push” directly to servers without a registry

#103

Post by lillecarl »

cyberax wrote: post #98
politelemon wrote: post #74

Considering the nature of servers, security boundaries and hardening, > Linux via Homebrew Please don't encourage this on Linux. It happens to offer a Linux setup as an afterthought but behaves like a pigeon on a chessboard rather than a package manager.

We're using it to distribute internal tools across macOS and Linux developers. It excels in this. Are there any good alternatives?

100% Nix, it works on every distro, MacOS, WSL2 and won't pollute your system (it'll create /nix and patch your bashrc on installation and everything from there on goes into /nix).

Re: Show HN: Unregistry – “docker push” directly to servers without a registry

#104

Post by kosolam »

jdsleppy wrote: post #100

I've been very happy doing this: DOCKER_HOST=“ssh://user@remotehost” docker-compose up -d It works with plain docker, too. Another user is getting at the same idea when they mention docker contexts, which is just a different way to set the variable. Did you know about this approach? In the snippet above, the image will be built on the remote machine and then run. The context (files) are sent over the wire as needed.…

This approach is akin to the prod server pulling an image from a registry. The op method is push based.

Re: Show HN: Unregistry – “docker push” directly to servers without a registry

#106

Post by felbane »

jillesvangurp wrote: post #76
psviderski wrote: post #3

Earlier quoted context omitted.

Thank you! Can you please clarify what kind of support you mean for docker compose?

Right now, I use ssh to trigger a docker compose restart that pulls all the latest images on some of my servers (we have a few dedicated hosting/on premise setups). That then needs to reach out to our registry to pull images. So, it's this weird mix of push pull that ends up needing a central registry. What would be nicer instead is some variation of docker compose pussh that pushes the latest versions of local image…

I've built a setup that orchestrates updates for any number of remotes without needing a permanently hosted registry. I have a container build VM at HQ that also runs a registry container pointed at the local image store. Updates involve connecting to remote hosts over SSH, establishing a reverse tunnel, and triggering the remote hosts to pull from the "localhost" registry (over the tunnel to my buildserver registry).

The connection back to HQ only lasts as long as necessary to pull the layers, tagging works as expected, etc etc. It's like having an on-demand hosted registry and requires no additional cruft on the remotes. I've been migrating to Podman and this process works flawlessly there too, fwiw.

Re: Show HN: Unregistry – “docker push” directly to servers without a registry

#107

Post by cyberax »

lillecarl wrote: post #103
cyberax wrote: post #98

Earlier quoted context omitted.

We're using it to distribute internal tools across macOS and Linux developers. It excels in this. Are there any good alternatives?

100% Nix, it works on every distro, MacOS, WSL2 and won't pollute your system (it'll create /nix and patch your bashrc on installation and everything from there on goes into /nix).

Downside: it's Nix.

I tried it, but I have not been able to easily replicate our Homebrew env. We have a private repo with pre-compiled binaries, and a simple Homebrew formula that downloads the utilities and installs them. Compiling the binaries requires quite a few tools (C++, sigh).

I got stuck at the point where I needed to use a private repo in Nix.

Re: Show HN: Unregistry – “docker push” directly to servers without a registry

#108

Post by lloeki »

cyberax wrote: post #107
lillecarl wrote: post #103

Earlier quoted context omitted.

100% Nix, it works on every distro, MacOS, WSL2 and won't pollute your system (it'll create /nix and patch your bashrc on installation and everything from there on goes into /nix).

Downside: it's Nix. I tried it, but I have not been able to easily replicate our Homebrew env. We have a private repo with pre-compiled binaries, and a simple Homebrew formula that downloads the utilities and installs them. Compiling the binaries requires quite a few tools (C++, sigh). I got stuck at the point where I needed to use a private repo in Nix.

> We have a private repo with pre-compiled binaries, and a simple Homebrew formula that downloads the utilities and installs them.

Perfectly doable with Nix. Ignore the purists and do the hackiest way that works. It's too bad that tutorials get lost on concepts (which are useful to know but a real turn down) instead of focusing on some hands-on practical how-to.

This should about do it and is really not that different nor difficult than formulas or brew install:

    git init mychannel
    cd mychannel
    
    cat > default.nix  { },
    }:
    
    {
      foo = pkgs.callPackage ./pkgs/foo { };
    }
    NIX
    
    mkdir -p pkgs/foo
    cat > pkgs/foo/default.nix  foo  foo!

    git add .
    git commit -a -m 'init channel'
    git add origin git@github.com:OWNER/mychannel
    git push origin main
    
    nix-channel --add https://github.com/OWNER/mychannel/archive/main.tar.gz mychannel
    nix-channel --update
    
    nix-env -iA mychannel.foo
    foo  # => foo!
(I just cobbled that up together, if it doesn't work as is it's damn close; flakes left as an exercise to the reader)

Note: if it's a private repo then in /etc/nix/netrc (or ~/.config/nix/netrc for single user installs):

    machine github.com
        password ghp_YOurToKEn
> Compiling the binaries requires quite a few tools (C++, sigh).

Instantly sounds like a whole reason to use nix and capture those tools as part of the dependency set.

Re: Show HN: Unregistry – “docker push” directly to servers without a registry

#109

Post by ajd555 »

This is great! I wonder how well it works in case of Disaster Recovery though. Perhaps it is not intended for production environments with strict SLAs and uptime requirements, but if you have 20 servers in a cluster that you're migrating to another region or even cloud provider, the pull approach from a registry seems like the safest and most scalable approach
Post reply on HN