5 ms·

I know this is not the recommended practice, but I am working on a legacy project where we need to migrate to Docker and the first step (before decomposing in m

I know this is not the recommended practice, but I am working on a legacy project where we need to migrate to Docker and the first step (before decomposing in multiple containers) would be to have an all-in-one container running all services. I am looking for hints / recommendations on the best way to do this. Can you provide any pointers ?

ffsm8 2y ago
Not the person you asked, but I've done something like that several years ago, too. From alpine RUN apk add --no-cache $yourDependencies Add theSoftware /bin/theSoftware CMD rc-service yourDependency start && /bin/theSoftware You probably want to make that CMD into a bash script, produce theSoftware in another "from $yourRuntime as builderImage" and COPY from=builderImage though I'd strongly encourage you to explore the image with dive after to visualize whats been added on which command while you're changing the dockerfile https://github.com/wagoodman/dive https://github.com/wagoodman/dive I'd push back on that being a good idea though. It's okayish, but it'd be better if the software had no dependencies, falling back to file storage/embedded DB. But that's obviously scope screep, so probably not worth the effort if your chosen framework doesn't give you a drop in option for that. Basically ymmv, I wouldn't touch a software that nests multiple daemons into the same image. It's a hack for easier demos or transient starts on dev machines, but that's it. Your orm does support sqlite though, that'd probably be better then nesting a database daemon
- grodriguez100 2y ago
  That’s useful, thanks. Will probably need to start with an Ubuntu image instead of Alpine to keep changes to a minimum. Recommendations for an “rc-service” to use in this context ?
  - nalbyuites 2y ago
    This has worked pretty well for me both for service control and pre-execution environment setup : https://github.com/just-containers/s6-overlay https://github.com/just-containers/s6-overlay There is also good old supervisord, but I haven't personally used it in containers yet. https://docs.docker.com/config/containers/multi-service_container/#use-a-process-manager https://docs.docker.com/config/containers/multi-service_cont...
  - akdev1l 2y ago
    If you use Ubuntu then just install systemd from the repos and use that imo. Less learning for you to do if you already know how services are configured in Ubuntu. You’ll need to point the entrypoint to /usr/bin/init.
freedomben 2y ago
You already know this, but I would be remiss if I didn't first point out that this is bad practice for a number of reasons. That said, I have had to do this before and if I ever have to do it again, I will be going right for a base image that has systemd. Red Hat provides UBI images that have systemd in it for reasons similar to this. Assuming that a pod or deployment using something like podman is not an option, This what I would use personally.

ffsm8 2y ago

Not the person you asked, but I've done something like that several years ago, too. From alpine RUN apk add --no-cache $yourDependencies Add theSoftware /bin/theSoftware CMD rc-service yourDependency start && /bin/theSoftware You probably want to make that CMD into a bash script, produce theSoftware in another "from $yourRuntime as builderImage" and COPY from=builderImage though I'd strongly encourage you to explore the image with dive after to visualize whats been added on which command while you're changing the dockerfile https://github.com/wagoodman/dive https://github.com/wagoodman/dive I'd push back on that being a good idea though. It's okayish, but it'd be better if the software had no dependencies, falling back to file storage/embedded DB. But that's obviously scope screep, so probably not worth the effort if your chosen framework doesn't give you a drop in option for that. Basically ymmv, I wouldn't touch a software that nests multiple daemons into the same image. It's a hack for easier demos or transient starts on dev machines, but that's it. Your orm does support sqlite though, that'd probably be better then nesting a database daemon

grodriguez100 2y ago
That’s useful, thanks. Will probably need to start with an Ubuntu image instead of Alpine to keep changes to a minimum. Recommendations for an “rc-service” to use in this context ?
- nalbyuites 2y ago
  This has worked pretty well for me both for service control and pre-execution environment setup : https://github.com/just-containers/s6-overlay https://github.com/just-containers/s6-overlay There is also good old supervisord, but I haven't personally used it in containers yet. https://docs.docker.com/config/containers/multi-service_container/#use-a-process-manager https://docs.docker.com/config/containers/multi-service_cont...
- akdev1l 2y ago
  If you use Ubuntu then just install systemd from the repos and use that imo. Less learning for you to do if you already know how services are configured in Ubuntu. You’ll need to point the entrypoint to /usr/bin/init.

freedomben 2y ago

You already know this, but I would be remiss if I didn't first point out that this is bad practice for a number of reasons. That said, I have had to do this before and if I ever have to do it again, I will be going right for a base image that has systemd. Red Hat provides UBI images that have systemd in it for reasons similar to this. Assuming that a pod or deployment using something like podman is not an option, This what I would use personally.