ancieque

I remember installing a metamod plugin to my cs 1.5 Server that added server side fog of war iirc. But i could be mixing things up.

While the way secrets work in Swarm seems weird when compared to Kubernetes, this is usually pretty easily solved by a quick overriding entrypoint in the docker stack file that does essentially this:

    export SOME_VAR=$(cat /run/secrets/some_secret)
    exec /original/entrypoint.sh

Speaking as a Co-Founder of NeuroForge here, with some exciting news: we're proud to announce a new alpha release for our project, Swarmgate - version 0.7.0. This tool, which started as a simple experiment within our team, has evolved into an essential project aimed at addressing the complex challenges of Docker Swarm management. Whether it's juggling multiple users in a single swarm or optimizing resources across various swarms, Swarmgate 0.7.0 is our latest answer to these issues, offering enhanced features and improvements. You can find it over at:

https://github.com/neuroforgede/swarmgate

What's Swarmgate? Swarmgate is our innovative Docker Socket Proxy designed to provide a tenant-specific view onto a Docker Swarm. It supports all necessary operations for deploying stacks, along with managing volumes, secrets, configs, networks, and more. This allows multiple teams to work collaboratively within the same cluster without interfering with each other, thanks to unique labels that filter requests based on resource ownership. It's about making Docker Swarm environments as efficient and user-friendly as possible.

Under the Hood:

We've built Swarmgate using Node.js and Express, with the dockerode (and docker-modem) library for Docker interaction. This technology stack ensures robust performance and seamless integration with Docker's API, providing a reliable and effective management tool.

What's New in 0.7.0?

    Docker Registry Auth Verification: Enhanced security through Docker Registry authentication checks to prevent unauthorized access to images.

    Security Enhancements: Removal of the :version/swarm endpoint to protect against potential security vulnerabilities by exposing swarm join tokens.

    Simplified Proxying: Introduction of the proxyRequestToDocker function for straightforward proxying of requests without the need for filtering.

    Resolved Log Issues: We've tackled service/tasks log parsing issues to ensure compatibility and ease of use with the Docker CLI.

As enthusiastic as we are about Swarmgate 0.7.0, it's important to remember that this is still ALPHA software. It's primarily a defense against accidental disruptions within clusters. While we're diligently enhancing security features, it's advisable to use Swarmgate in environments where there's a high level of trust among users.

What's up next:

    A better tutorial on how to set this up

    More ideas from https://github.com/neuroforgede/swarmgate/issues/1

Cool to see this.

I love DRF for CRUD apis. It just gets the job done and you can Focus on data modelling.

We built our data hub/data Integration solution on top of it. [1] It was a good choice.

By far the most extensible and overridable library I have worked with so far. Even when you need to ressort to hacks, they never seem to break when upgrading a Version.

[1] https://github.com/neuroforgede/nfcompose

If you want to stick on one machine, you can always just use a single node Docker Swarm to get the fully automated zero downtime deploys you want with Docker Compose:

https://github.com/BretFisher/ama/discussions/146

I have implemented this for our tool NF Compose that allows us to build REST APIs without writing a single line of code [0]. I didn't go the route of triggers because we generate database tables automatically and we used to have a crazy versioning scheme that was inspired by data vault and anchor modelling where we stored every change on every attribute as a new record. This allowed for simple point in time queries.

Sounded cool, but in practice it was really slow. The techniques that are usually employed by Data Vault to fix this issue seemed too complex. Over time we moved to an implementation that handles the historization dynamically at runtime by generating historizing SQL queries ourselves [1]. We now use transaction time to determine winners and use an autoincrementing column to determine who wins on ties. A lot of brainpower went into ensuring this design is concurrency safe. On a sidenote: Generating SQL in python sounds dangerous, but we spent a lot of time on making it secure. We even have a linter that checks that everything is escaped properly whenever we are in dev mode [2].

[0] https://github.com/neuroforgede/nfcompose/

[1] https://github.com/neuroforgede/nfcompose/blob/main/skipper/...

[2] https://github.com/neuroforgede/nfcompose/blob/main/skipper/...

Ah and a side note: Superset allows to template SQL queries via jinja. Works very well.

Curious, have you tried speeding things up with e.g. cube.js? We used it in a fully custom project and it was a Performance life saver. It works quite well with Superset actually.

We have looked into metabase ourselves initially as well but found it lacking compared to Superset. What are your thoughts on that?

Note that we build dashboards for customers that end up having some complex SQL directly in Superset.

Docker Swarm engine is part of docker-ce. It just got New features last year as well as some quality of life improvements.

Its not shiny but it works. We use it for most of our selfhosted stuff (which is a lot) and our customers.

I host a swarm fans hangout every 2 months over at devops.fan with Bret Fisher. Also we help each other on discord. Join us :)

Because I didn't like the name, I just renamed it to swarmgate.

CSI support will hopefully make this easier. But: there are quite some options once you Look deeper.

Also the volume plugin spec is so simple that it is possible to maintain your own plugin (even without csi).

What do you need from the managed dbs?

I saw your comment and am wondering what in particular you are struggling with.

I recently fixed one of my biggest pet peeves with docker swarm - the inability to directly exec into a service without first SSHing to the host the task is running on.

https://github.com/neuroforgede/docker-swarm-proxy

Maybe your issue is in this ballpark? Happy to exchange notes on this. If you are looking for a community of Swarm users, check out https://devops.fan (that's a discord hosted by Bret Fisher)

Yeah, had a fun time yesterday when writing a tutorial. Was kinda reliably switching between good and bad every few seconds.

So does this work with Docker Swarm out of the box? I guess this breaks the default networking stack of Swarm, right?

TL;DR: Update your clusters.

we use https://github.com/costela/docker-volume-hetzner which is really stable.

CSI support for Swarm is in beta as well and already merged in the Hetzner CSI driver (https://github.com/hetznercloud/csi-driver/tree/main/deploy/...). There are some rough edges atm with Docker + CSI so I would stick with docker-volume-hetzner for now for prod usage.

Disclaimer: I contributed to both repos.

We use Docker Swarm for our deployments, so I will answer the questions based on that.

We have built some tooling around setting up and maintaining the swarm using ansible [0]. We also added some Hetzner flavour to that [1] which allows us to automatically spin up completely new clusters in a really short amount of time.

deploy from source repo:

- We use Azure DevOps pipelines that automate deployments based on environment configs living in an encrypted state in Git repos. We use [2] and [3] to make it easier to organize the deployments using `docker stack deploy` under the hood.

keep software up to date:

- We are currently looking into CVE scanners that export into prometheus to give us an idea of what we should update

load balancing:

- depending on the project, Hetzner LB or Cloudflare

handle scaling:

- manually, but i would love to build some autoscaler for swarm that interacts with our tooling [0] and [1]

automate backups:

- docker swarm cronjobs either via jobs with restart condition and a delay or [4]

maintain security:

- Hetzner LB is front facing. Communication is done via encrypted networks inside Hetzner private cloud networks

- [0] https://github.com/neuroforgede/swarmsible

- [1] https://github.com/neuroforgede/swarmsible-hetzner

- [2] https://github.com/neuroforgede/nothelm.py

- [3] https://github.com/neuroforgede/docker-stack-deploy

===================

EDIT - about storage:

We use cloud volumes.

For drivers:

We use https://github.com/costela/docker-volume-hetzner which is really stable.

CSI support for Swarm is in beta as well and already merged in the Hetzner CSI driver (https://github.com/hetznercloud/csi-driver/tree/main/deploy/...). There are some rough edges atm with Docker + CSI so I would stick with docker-volume-hetzner for now for prod usage.

Disclaimer: I contributed to both repos.

GSoC is a remnant of the old Google. Glad to see it is still there.

Swarm still is a thing. The recentl docker release even has new features in it.

Also see https://github.com/BretFisher/awesome-swarm

Docker stacks are essentially docker compose files with some extra Features.

Docker compose is a developer tool for use on a single computer.

Docker Swarm is a container orchestrator like Kubernetes or Nomad

You may like the new release of moby 23.0.0 then :)

see https://docs.docker.com/engine/release-notes/23.0/

the community is working on adding Swarm support to CSI vendors:

https://github.com/olljanat/csi-plugins-for-docker-swarm

This still is Docker Swarm.

The news about its death are just plain wrong. There are new features in the most recent release of moby/moby and development in general has been picking up again:

https://docs.docker.com/engine/release-notes/23.0/

Classic Swarm was deprecated and hardly anyone has been using it.

Swarm mode, which everyone usually is talking about is not being deprecated. Docker 23.0.0 shipped with new features for Docker Swarm.

https://docs.docker.com/engine/release-notes/23.0/

https://www.bretfisher.com/

Swarm development is picking up again it seems. Good news.

JSON is arguably much worse for usage in Git. Have fun matching braces in the default diff tools out in the wild.

YAML is the much better alternative with similar semantics to JSON. The numeric issues still hold true though.

I guess this can easily be scripted with https://pypi.org/project/yq/ Internally this seems to be a wrapper around jq :)

I stumbled across this today. Really interesting product that they are building. Also they support both kubernetes and Docker APIs but only as shims to their orchestration.

From their page: kraud is bringing the cloud home. Docker and Kubernetes Hybrid cloud with confidentiality and carbon-negativity