Should I move to Docker?

Submitted ⁨⁨11⁩ ⁨months⁩ ago⁩ by ⁨GreatBlueHeron@lemmy.ca⁩ to ⁨selfhosted@lemmy.world⁩

I’m a retired Unix admin. It was my job from the early '90s until the mid '10s. I’ve kept somewhat current ever since by running various machines at home. So far I’ve managed to avoid using Docker at home even though I have a decent understanding of how it works - I stopped being a sysadmin in the mid '10s, I still worked for a technology company and did plenty of “interesting” reading and training.

It seems that more and more stuff that I want to run at home is being delivered as Docker-first and I have to really go out of my way to find a non-Docker install.

I’m thinking it’s no longer a fad and I should invest some time getting comfortable with it?

source

Comments

Sort:hotnew top

Gooey0210@sh.itjust.works ⁨11⁩ ⁨months⁩ ago
Nixos, nixos, nixos 🤌

source
- fruitycoder@sh.itjust.works ⁨11⁩ ⁨months⁩ ago
  Both! Sandboxing from containers and configuration control from nix go well together!
  
  source
  - Gooey0210@sh.itjust.works ⁨11⁩ ⁨months⁩ ago
    You can use the sandboxing of nixos
    
    You get better performance, nixos level reproducibility, and it’s not docker which is not foss and running with root
    
    source
    -> View More Comments
- milicent_bystandr@lemm.ee ⁨11⁩ ⁨months⁩ ago
  Does Docker still give a security benefit over NixOS, because of the sandboxing?
  
  source
  - dan@upvote.au ⁨11⁩ ⁨months⁩ ago
    There’s still benefits to Docker. If you care a lot about security, make sure Docker is running in rootless mode.
    
    source
    -> View More Comments
aniki@lemm.ee ⁨11⁩ ⁨months⁩ ago
Welcome to Docker! It’s fucking awesome! One thing to remember is:

PLEASE setup root-less Docker. It’s safer, easier [no sudo all the fking time.], and literally zero downsides other than the initial configuration – but the Docker docs are amazing and they have every distro on there. It’s only a few more steps and you can sleep secure in the fact that even in the WORST case scenario [compromised to root], they still only have a container running in userspace.

source
onlinepersona@programming.dev ⁨11⁩ ⁨months⁩ ago
Why wouldn’t you want to use containers? I’m curious. What do you use now? Ansible? Puppet? Chef?

source
- GreatBlueHeron@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  Currently no virtualisation at all - just my OS on bare metal with some apps installed. Remember, this is a single machine sitting in my basement running Samba and a couple of other things - there’s not much to orchestrate :-)
  
  source
  - onlinepersona@programming.dev ⁨11⁩ ⁨months⁩ ago
    Oh, I thought you had multiple machines.
    
    I use docker because each service I use requires different libraries with different versions. With containers, that doesn’t matter. It also provides some rudimentary security. If an attacker gets in, they’ll have to break out of the container first to get at the rest of the system. Each container can run with a different user, so even if they do get out of the container, at worst they’ll be able to destroy the data they have access to - well, they’ll still see other stuff in the network, but I think it’s better than being straight pwned.
    
    source
  - pete_the_cat@lemmy.world ⁨11⁩ ⁨months⁩ ago
    It makes deployments a lot easier once you have the groundwork laid (writing your compose files). If you ever need to nuke the OS reinstalling and configuring 20+ apps can only take a few minutes (assuming you still have the config data, which should live outside of the container).
    
    For example, setting up my mediaserver, webserver, SQL server, and usenet suit of apps can take a few hours to do natively. Using Docker Compose it takes one command and about 5-10 minutes. Granted, I had to spend a few hours writing the compose files and testing everything, along with storing the config data, but just simply backing up the compose files with git means I can pull everything down quickly. Even if I don’t have the config files anymore it probably only takes like an hour or less to configure everything.
    
    source
- Dyskolos@lemmy.zip ⁨11⁩ ⁨months⁩ ago
  Not OP, but, seriously asking, why should I? I usually still use VMs for every app i need. Much more work I assume, but besides saving time (and some overhead and mayve performance) what would I gain from docker or other containers?
  
  source
  - MostlyGibberish@lemm.ee ⁨11⁩ ⁨months⁩ ago
    One of the things I like about containers is how central the IaC methodology is. There are certainly tools to codify VMs, but with Docker, right out of the gate, you’ll be defining your containers through a Dockerfile, or docker-compose.yml, or whatever other orchestration platform. With a VM, I’m always tempted to just make on the fly config changes directly on the box, since it’s so heavy to rebuild them, but with containers, I’m more driven to properly update the container definition and then rebuild the container. Because of that, you have an inherent backup that you can easily push to a remote git server or something similar. Maybe that’s not as much of a benefit if you have a good system already, but containers make it easier imo.
    
    source
    -> View More Comments
  - SpaceCadet@feddit.nl ⁨11⁩ ⁨months⁩ ago
    
    what would I gain from docker or other containers?
    
    Reproducability.
    
    Once you’ve built the Dockerfile or compose file for your container, it’s trivial to spin it up on another machine later. It’s no longer bound to the specific VM and OS configuration you’ve built your service on top of and you can easily migrate containers or move them around.
    
    source
    -> View More Comments
  - pete_the_cat@lemmy.world ⁨11⁩ ⁨months⁩ ago
    VMs have a ton of overhead compared to Docker. VMs replicate everything in the computer while Docker just uses the host for everything, except it sandboxes the apps.
    
    In theory, VMs are far more secure since they’re almost entirely isolated from the host system (assuming you don’t have any of the host’s filesystems attached), they are also OS agnostic whereas Docker is limited to the OS it runs on.
    
    source
    -> View More Comments
  - criticalimpact@lemm.ee ⁨11⁩ ⁨months⁩ ago
    Saves time, minimal compatibility, portability and you can update with 2 commands There’s really no reason not to use docker
    
    source
    -> View More Comments
irotsoma@lemmy.world ⁨11⁩ ⁨months⁩ ago
Docker is nice for things that have complex installations and I want a very specific implementation that I don’t plan to tweak very much. Otherwise, it’s more hassle than it’s worth. There are lots of networking issues like limited/experimental support for IPv6, and too much is hidden and preconfigured, making it difficult to make adjustments that would otherwise just be a config file change.

So it is good for products like a mail server where you want to use the exact software they use like let’s say postfix + dovecot + roundcube + nginix + acme + MySQL + spam assassin + amavisd, etc. But you want to use an existing reverse proxy and cert it setup, or want to use a different spam filter or database and it becomes a huge hassle.

source
- dan@upvote.au ⁨11⁩ ⁨months⁩ ago
  I haven’t had any issues with IPv6. If you want to, you can just use a macvlan network and rely on SLAAC. I manually assigned ULA addresses to some containers and it’s working well.
  
  Also as a side note, it’s not common for mail servers to use SpamAssassin any more. Most have moved to rspamd which is more powerful and much more efficient.
  
  source
quackers@lemmy.blahaj.zone ⁨11⁩ ⁨months⁩ ago
It’s quite easy to use once you get the hang of it. In most situations, it’s the prefered option because you can just have your docker container, choose where relevant files are allowing you to properly isolate your applications. Or on single purpose servers, it makes deployment of applications and maintaining dependencies significantly easier.
At the very least, it’s a great tool to add to your toolbox to use as needed.

source
SeeJayEmm@lemmy.procrastinati.org ⁨11⁩ ⁨months⁩ ago
I was like you and avoided it for a long time. Dedicated use, lean VMs for each thing I was running. I decided to learn it, mostly out of curiosity and I’ll be honest, I like the convenience of it a lot. They’re easier to deploy and tend to have lower overhead than a single purpose VM running the same software.

Around the same time I switched my VM server over to Proxmox and learned about LxC containers. Those are also pretty nifty and a nice middle ground between full VM and docker container.

Currently I have a mixed environment because I like to use my homelab to learn, but most new stuff I deploy tends to go in this order: Docker > LxC > full VM.

source
WindowsEnjoyer@sh.itjust.works ⁨11⁩ ⁨months⁩ ago
If you have homelab and not using containers - you are missing out A LOT! Docker-compose is beautiful thing for homelab. <3

source
- pete_the_cat@lemmy.world ⁨11⁩ ⁨months⁩ ago
  It took me a while to convert to Docker, I was used to installing packages for all my Usenet and media apps, along with my webserver. I tried Docker here and there but always had a random issue pop up where one container would lose contact with the other, even though they were in the same subnet. Since most containers only contain the bare minimum, it was hard to troubleshoot connectivity issues. Frustrated, I would just go back to native apps.
  
  About a year or so ago, I finally sat down and messed around with it a lot, and then wrote a compose file for everything. I’ve been gradually expanding upon it and it’s awesome to have my full stack setup with like 20 containers and their configs, along with an SSL secured reverse proxy in like 5-10 minutes! I have since broken out the compose file into multiple smaller files and wrote a shell script to set up the necessary stuff and then loop through all the compose files, so now all it takes is the execution of one command instead of a few hours of manual configuration!
  
  source
DontNoodles@discuss.tchncs.de ⁨11⁩ ⁨months⁩ ago
I hate it very much. I am sure it is due to my limited understanding of it, but I’ve been stuck on some things that were very easy for me using VM.

We have two networks, one of which has very limited internet connectivity, behind proxy. When using VMs, I used to configure everything: code, files, settings on a machine with no restrictions; shut it down; move the VM files to the restricted network; boot and be happily on my way.

I’m unable to make this work with docker. Getting my Ubuntu server fetch its updates behind proxy is easy enough; setting it for python Pip is another level; realising the specific python libraries need special keys to work around proxies is yet another; figuring out how to get it done for Docker and python under it is when I gave up. Why can it not be as simple as the VM!

Maybe I’m not looking using the right terms or maybe I should go and learn docker “properly”, but there is no doubt that using Docker is much more difficult for my use case than using VMs.

source
- cozycosmic@lemmy.world ⁨11⁩ ⁨months⁩ ago
  You are right. Either you are using docker very wrong, or docker is not meant for this use case.
  
  You say “getting ubuntu server to fetch it’s updated behind proxy”. You shouldn’t be updating Ubuntu from inside of docker. Instead, the system should be somewhat immutable. You should configure the version you want to use as part of the Docker file.
  
  Same with python and keys. You likely want to install python dependencies in the Dockerfile, so that you can install them once and it becomes bundled into the container image. Then you don’t need to use pip behind the proxy.
  
  source
  - DontNoodles@discuss.tchncs.de ⁨11⁩ ⁨months⁩ ago
    I’m not much into new year resolutions, but I think I’ll make a conscious effort to learn Docker in the coming months. Any suggestions for good guides for someone coming from VM end will be appreciated.
    
    source
    -> View More Comments
- SpaceCadet@feddit.nl ⁨11⁩ ⁨months⁩ ago
  Huh? Your docker container shouldn’t be calling pip for updates at runtime, you should consider them immutable and ephemeral. Build your container (presumably pip-ing in all the libraries you require) on the machine with full network access, then export or publish the container image and run it on the machine with limited access. If you want updates, you regularly rebuild the container image and repeat.
  
  Alternatively, even at build time it’s fairly easy to use a proxy with docker, unless you have some weird proxy configuration. I use it here so that updates get pulled from a local caching proxy, reducing my internet traffic and making rebuilds quicker.
  
  source
  - DontNoodles@discuss.tchncs.de ⁨11⁩ ⁨months⁩ ago
    I think I’m not aware of the exporting/publishing part and that’s the cause of my woes. I get everything running on the machine with unrestricted access, move to the machine with restricted access go “docker compose up” and get stuck. I’ll read up on exporting/publishing, thank you.
    
    source
marzhall@lemmy.world ⁨11⁩ ⁨months⁩ ago
It’s convenient. Can’t hurt to get used to it, for sure, in that it’s useful to not have to go through dependency hell installing things sometimes. It’s based on kernel features I don’t see Linus pulling out, so I think you’ll only see it more.

As someone who runs nix-only at home, I mostly use its underlying tech in the form of snaps/flatpaks, though. I use docker itself at work constantly, but at home, snaps/flatpaks tend to do the “minimize thinking about dependencies and building” bit but in a workflow more convenient for desktop applications.

source
- zingo@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  Yeah. Docker for servers.
  
  Flatpak for Desktops/Laptops.
  
  source
x3i@lemmy.x3i.tech ⁨11⁩ ⁨months⁩ ago
Yes. Let me give you an example on why it is very nice: I migrated one of my machines at home from an old x86-64 laptop to an arm64 odroid this week. I had a couple of applications running, 8 or 9 of them, all organized in a docker compose file with all persistent storage volumes mapped to plain folders in a directory. All I had to do was stop the compose setup, copy the folder structure, install docker on the new machine and start the compose setup. There was one minor hickup since I forgot that one of the containers was built locally but since all the other software has arm64 images available under the same name, it just worked. Changed the host IP and done.

One of the very nice things is the portability of containers, as well as the reproducibility (within limits) of the applications, since you divide them into stateless parts (the container) and stateful parts (the volumes), definitely give it a go!

source
alphacyberranger@lemmy.world ⁨11⁩ ⁨months⁩ ago
Learning docker is always a big plus. It’s not hard. If you are comfortable with cli commands, then it should be a breeze. Even if you are not comfortable, you should get used to it very fast.

source
SpaceCadet@feddit.nl ⁨11⁩ ⁨months⁩ ago
I think it’s a good tool to have on your toolbelt, so it can’t hurt to look into it.

Whether you will like it or not, and whether you should move your existing stuff to it is another matter. I know us old Unix folk can be a fussy bunch about new fads (I started as a Unix admin in the late 90s myself).

Personally, I find docker a useful tool for a lot of things, but I also know when to leave the tool in the box.

source
Presi300@lemmy.world ⁨11⁩ ⁨months⁩ ago
Yeh, I’m not a system admin in any meaning of the word, but docker is so simple that even I got around to figuring it out and it just exists to save time and prevent headaches (dependency hell)

source
floridaman@lemmy.blahaj.zone ⁨11⁩ ⁨months⁩ ago
Some people seem to hate on it, but I love Docker, it works well for what it has to do and has relatively low overhead as far as I can tell. I personally virtualize a Debian server on Proxmox for my containers just so as to keep everything even more compartmentalized, but it takes more work than it’s worth to set up.

And if you don’t like Docker for whatever reason, you can also try Podman which is API compatible with Docker for the most part.

source
TheHolm@aussie.zone ⁨11⁩ ⁨months⁩ ago
Try other container technologies lie LXC or go right side and play with FreeBSD jails. Quality of dockers you can find around is horrendous, giving that Docker itself build for convenience not security. It is not something I will trust.

source
- valaramech@kbin.social ⁨11⁩ ⁨months⁩ ago
  There's nothing wrong with OCI Images. If you're concerned about the security of Docker (which, imo, you should be) there are other container runtimes that don't have its security tradeoffs (e.g. podman).
  
  source
- Toribor@corndog.social ⁨11⁩ ⁨months⁩ ago
  Once I got to the point where I was running a ton of containers I’d occasionally have issues where a maintainer wouldn’t resolve issues fast enough for my liking so I started building more containers myself which was a lot easier than I’d anticipated.
  
  source
avidamoeba@lemmy.ca ⁨11⁩ ⁨months⁩ ago
Why would you try avoiding it if you understand how it works? It has so many upsides and so few downsides. About the only practical one is using more disk space.

source
- GreatBlueHeron@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  Because it seems overkill for a home server. Up until recently all I ran was Samba and a torrent daemon. Why would I install another layer of overhead to manage two applications on one server?
  
  source
  - avidamoeba@lemmy.ca ⁨11⁩ ⁨months⁩ ago
    Because the overhead is almost none. Maybe it’s not worth using it for Samba and Transmission. But involve OpenVPN for Transmission in the mix and things get a lot more complicated if Samba has to keep serving LAN and Transmission has to stop if OpenVPN stops. If instead you grab this, the problem is solved by writing one 20-line docker-compose.yml and doing docker-compose up -d:
    
    version: '3.3' services: transmission-openvpn: cap_add: - NET_ADMIN volumes: - '/your/storage/path/:/data' - '/your/config/path/:/config' environment: - OPENVPN_PROVIDER=PIA - OPENVPN_CONFIG=france - OPENVPN_USERNAME=user - OPENVPN_PASSWORD=pass - LOCAL_NETWORK=192.168.0.0/16 logging: driver: json-file options: max-size: 10m ports: - '9091:9091' restart: on-failure image: haugene/transmission-openvpn
    
    source
jrbaconcheese@yall.theatl.social ⁨11⁩ ⁨months⁩ ago
As someone who is not a former sysadmin and only vaguely familiar with *nix, I’ve been able to turn my home NAS (bought strictly to hold photos and videos backed up from our phones) into a home media sever by installing Docker and learning home the yml files work and it’s been awesome

source
Smk@lemmy.ca ⁨11⁩ ⁨months⁩ ago
I would never go back installing something without docker. Never.

source
- pete_the_cat@lemmy.world ⁨11⁩ ⁨months⁩ ago
  For a lot of smaller things I feel that Docker is overkill, or simply not feasible (package management, utilities like screenfetch, text editors, etc…) but for larger apps it definitely makes it easier once you wrap your head around containerization.
  
  For example, I switched full-time to Jellyfin from Plex and was attempting to use caddy-docker-proxy to forward the host network that Jellyfin uses to the Caddy server, but I couldn’t get it to work automatically (explicitly defining the reverse proxy in the Caddyfile works without issue). I thought it would be easier to just install it natively, but since I hadn’t installed it that way in a few years I forgot that it pulls in like 30-40 dependencies since it’s written in .Net (or would that be C#?) and took a good few minutes to install. I said screw that and removed all the deps and went back to using the container and just stuck with the normal version of Caddy which works fine.
  
  source
P1r4nha@feddit.de ⁨11⁩ ⁨months⁩ ago
Definitely not a fad. It’s used all over the industry. It gives you a lot more control over the environment where your hosted apps run. There may be some overhead, but it’s worth it.

source
Boomkop3@reddthat.com ⁨6⁩ ⁨months⁩ ago
It’s basically a vm without the drawbacks of a vm, why would you not? It’s hecking awesome

source
Agent_Engelbert@linux.community ⁨11⁩ ⁨months⁩ ago
There are teachings I have read/ discovered through YouTube (can’t remember exactly where) about the reasons and the philosophy behind moving to docker, or having it as a state machine.

Have you considered looking into dockers alternatives, also ?

Here is 1 of the sources that may give you insights:

www.cloudzero.com/blog/docker-alternatives/

– There has been some concerns over docker’s licensing and, as such, some people have started preferring solutions such as podman and containerd.

Both are good in terms of compatibility and usability, however I have not used them extensively.

Nonetheless, I am currently using docker for my own hyperserver purposes. And I am also a little concerned about the future of docker, and would consider changing sometime in the future.

source
lefaucet@slrpnk.net ⁨11⁩ ⁨months⁩ ago
i use it for gitea, nextcloud, redis, postgres, and a few rest servers and love it!, super easy

it can suck for things like homelab stablediffusion and things that require gpu or other hardware.

source
- Aiyub@feddit.de ⁨11⁩ ⁨months⁩ ago
  As someone who does AI for a living: GPU+docker is easy and reliable. Especially if you compare it to VMs.
  
  source
  - lefaucet@slrpnk.net ⁨11⁩ ⁨months⁩ ago
    good to hear. maybe I should try again
    
    source
- SpaceCadet@feddit.nl ⁨11⁩ ⁨months⁩ ago
  
  postgres
  
  I never use it for databases. I find I don’t gain much from containerizing it, because the interesting and difficult bits of customizing and tayloring a database to your needs are on the data file system or in kernel parameters, not in the database binaries themselves. On most distributions it’s trivial to install the binaries for postgres/mariadb or whatnot.
  
  Databases are usually fairly resource intensive too, so you’d want a separate VM for it anyway.
  
  source
  - lefaucet@slrpnk.net ⁨11⁩ ⁨months⁩ ago
    Very good points.
    
    In my case I just need to for a couple users with maybe a few dozen transactions a day; it’s far from being a bottleneck and there’s little point in optimizing it further.
    
    Containerizing it also has the benefit of boiling all installation and configuration into one very convenient dockercompose file… Actually two. I use one with all the config stuff that’s published to gitea and one that has sensitive data.
    
    source
ExLisper@linux.community ⁨11⁩ ⁨months⁩ ago
I’m thinking about moving to Korea. Not forever but for a year or two. Learn the language, know the culture, disconnect for a bit and come back to EU. How’s the IT job market there? Is it doable?

source
- monsdar@feddit.de ⁨11⁩ ⁨months⁩ ago
  Excuse me sir, this is a Wendy’s
  
  source
excitingburp@lemmy.world ⁨11⁩ ⁨months⁩ ago
Don’t learn Docker, learn containers. Docker is merely one of the first runtimes, and a rather shit one at that (it’s a bunch of half-baked projects - container signing as one major example).

Learn Kubernetes, k3s is probably a good place to start. Docker-compose is simply a proprietary and poorly designed version of it. If you know Kubernetes, you’ll quickly be able to pick up docker-compose if you ever need to.

You can use buildah bud (part of the Podman ecosystem) to build containerfiles (exactly the same thing as dockerfiles without the trademark). Buildah can also be used without containerfiles (your containerfiles simply becomes a script in the language of your choice - e.g. bash), which is far more versatile. Speaking of Podman, if you want to keep things really simple you can manually create a bunch of containers in a pod and then ask Podman to create a set of systemd units for you. Podman supports nearly all of what docker does (with exception to docker’s bjorked signing) and has identical command line syntax. Podman can also host a docker-compatible socket if you need to use it with something that really wants docker.

I’m personally a big fan of Podman, but I’m also a fan of anything that isn’t Docker: LXD is another popular runtime, and containerd is (IIRC) the runtime underpinning docker. There’s also firecracker or kubevirt, which go full circle and let you manage tiny VMs like containers.

source
- GreatBlueHeron@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  All that makes sense - except that I’m taking about 1or 2 physical servers at home and my only real motivation for looking into containers at all is that some software I’ve wanted to install recently has shipped as docker compose scripts. If I’m going to ignore their packaging anyway, and massage them into some other container management system, I would be happier just running them of bare metal like I’ve done with everything else forever.
  
  source
roofuskit@lemmy.world ⁨11⁩ ⁨months⁩ ago
Dear God yes. It makes life a lot easier. It’s very easy to use and understand.

I have a feeling that once you’ve used it you’ll be kicking yourself for not doing so sooner.

source
akash_rawal@lemmy.world ⁨11⁩ ⁨months⁩ ago
As someone who is operating kubernetes for 2 years in my home server, using containers is much more maintainable compared to installing everything directly on the server.

I tried using docker-compose first to manage my services. It works well for 2-3 services, but as the number of services grew they started to interfere with each other, at that point I switched to kubernetes.

source
- Kialdadial@iusearchlinux.fyi ⁨11⁩ ⁨months⁩ ago
  If your compose files are conflicting then you’re likely not tailoring your compose files to fit your server.
  
  source
  - akash_rawal@lemmy.world ⁨11⁩ ⁨months⁩ ago
    I was writing my own compose files, but see my response to a sibling comment for the issue I had.
    
    source
- GreatBlueHeron@lemmy.ca ⁨11⁩ ⁨months⁩ ago
  Wow - I thought docker was overkill for a home server and you’ve gone kubernetes! I guess if you use it for work and that’s what you’re comfortable with?
  
  source
  - akash_rawal@lemmy.world ⁨11⁩ ⁨months⁩ ago
    Thank you… I had to learn kubernetes for work and it was around 2 weeks of time investment and then I figured out I could use it to fix my docker-compose pains at home.
    
    If you run a lot of services, I can attest that kubernetes is definitely not overkill, it is a good tool for managing complexity. I have 8 services on a single-node kubernetes and I like how I can manage configuration for each service independent of each other and also the underlying infrastructure.
    
    source
- null@slrpnk.net ⁨11⁩ ⁨months⁩ ago
  
  It works well for 2-3 services, but as the number of services grew they started to interfere with each other
  
  Can you expand on that? I use docker-compose and have probably around 10 services on the same box. I don’t forsee any limitations beyond hardware if I wanted to just keep adding more, but maybe I’m missing something.
  
  source
  - akash_rawal@lemmy.world ⁨11⁩ ⁨months⁩ ago
    If one service needs to connect to another service then I have to add a shared network between them. In that case, the services essentially shared a common namespace regarding DNS. DNS resolution would routinely leak from one service to another and cause outages, e.g if I connect Gitlab container and Redmine container with OpenLDAP container then sometimes Redmine’s nginx container would access Gitlab container instead of Redmine container and Gitlab container would access Redmine’s DB instead of its own DB.
    
    I maintained some workarounds, like starting Gitlab after starting Redmine would work fine but starting them other way round would have this issue. But switching to Kubernetes and replacing the cross-section connections with network policies solved the issue for me.
    
    source
    -> View More Comments
Decronym@lemmy.decronym.xyz ⁨11⁩ ⁨months⁩ ago
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

Fewer Letters More Letters

DNS Domain Name Service/System

IP Internet Protocol

NAS Network-Attached Storage

[Thread #349 for this sub, first seen 13th Dec 2023, 17:15] [FAQ] [Full list] [Contact] [Source code]

source
slazer2au@lemmy.world ⁨11⁩ ⁨months⁩ ago
I am a network engineer and I am learning it. I see it in the next step from the bare metal -> virtualisation evolution

source

Fewer Letters	More Letters
DNS	Domain Name Service/System
IP	Internet Protocol
NAS	Network-Attached Storage