I think my problem is that I still do not quite understand some features of Phoenix components.
Thanks to your suggestion, I just made some search on how not to mount a Phoenix endpoint and I found this blog post that gives me a lot of details on one easy way to implement Routing in Phoenix Umbrella Apps.
it’s a bit outdated, but I should be able to adapt it to Phoenix 1.4 projects.
To quickly sum up the post, I will add a third minimal Phoenix app (proxy_app) to the umbrella project. That app will be the main point of contact to the outside world (or one of the existing app could also play this role as you suggested).
Since this app will be the actual web server, we should disable the server setting in the other two:
I think @Nvim meant how to deploy a phoenix application without a reverse proxy like nginx in front of it. Hence the “only cowboy”.
Op: I think you should not forgoe setting up a reverse proxy in front of you application. From an ops perspective it is probably much easier to integrate nginx with an automated SSL setup. Also you get things like rate limiting, basic auth, static file handling, etc. out of the box with nginx.
I deploy docker’s for my personal projects. At work I deploy into a systemd management full VM, so systemd manages all the launching and so forth. I’ve documented how in PidFile - create and manage a PID file from the BEAM process if curious, but I recommend docker when possible.
No guide but nothing special about it. I just have a builder image that brings in otp/elixir/rust, builds, then copies the compiled release to the main image and run that, nothing special or out of the norm.
Why would you need a release or deploy commands? The ‘release’ is building the image, the deploy is loading the docker image, docker handles it all.
You mean that docker does docker build --tag organization/project:tag .?
So this is what I want to wrap in the Elixir Docker Stack, plus the build arguments. Basically just a simple wrapper around this command, that will use a Docker image in the root of the project or a default one provided by the stack.
When i used the term deploy I was not referring to docker deploy, but instead to a command to deploy the release into the target server.
If I end-up to include the release and deploy commands in the Elixir Docker Stack, they will target only pet projects that we deploy to the likes of Digital Ocean, Linode or similar.
I don’t even make a wrapper because I make a different tag much of the time (so I have a couple old versions around in case I need to switch back to them quickly), it’s simple enough as it is.
I use docker swarm with docker compose for that, so it’s still docker. ^.^
Yes, that’s what Docker Swarm does, it can deploy into remote systems.
Docker-Compose defines how it is setup and what it links with.
And Docker itself does the containerization handling.
They are all installed with docker itself as they are just other parts of the docker ecosystem.
Yep, docker-swarm does the orchestration, it allows you to deploy to many systems at once, a specific system of a specific types, etc… etc… etc…
It uses docker-compose to actually do the setup on the remote systems after it’s deployed it.
And docker-compose uses docker to containerize.
It’s just a lot of layers, like an onion or an ogre. ^.^
I use Docker a lot for my development workflow, but never to release and deploy to production, thus I have a lot of catch-up to do here
For now I will keep the Elixir Docker Stack with focus on an easy development workflow, and with the option for compiling Erlang, Elixir and Phoenix from their git repos.
Later I will look if it makes sense to wrap docker swarm and the docker compose file
After running phx.server on detached mode, I can its id using ps command. How do I find phx.server’s id quickly just I need to use kill command o stop it? Also is it better to put phx.server on systemd? Any examples on putting phxserver on systemd?