I have followed this tutorial https://gist.github.com/jswny/83e03537830b0d997924e8f1965d88bc
successifully but I have no idea how to deploy the result container to digital ocean.
Please help.
I have followed this tutorial https://gist.github.com/jswny/83e03537830b0d997924e8f1965d88bc
successifully but I have no idea how to deploy the result container to digital ocean.
Please help.
Try to create a droplet with CoreOS template in Digital Ocean.
CoreOS is a specialised Operating System to run containers, thus Docker is supported out of the box.
I have note read the gist, thus I cannot tell you exactly the docker command, but if the gist has it than you should only need to run it on the droplet shell. This assumes that the Gist tells how to create the docker image and how to upload it to a private registry.
If not you can always use the Gitlab private registry for containers https://about.gitlab.com/2016/05/23/gitlab-container-registry and if you want to go further you can use their Auto DevOps for automated deployments as per https://docs.gitlab.com/ee/topics/autodevops.
@Exadra37
I created an Ubuntu droplet and then added my code via git and it worked.I asked this question because am not sure if that is the best approach.
Thanks for your answer.
Hi, author of the tutorial here, glad you enjoyed the guide! I actually use this strategy on my own $20 DigitalOcean droplet. If you have a lower tier droplet, you might not be able to build the release on the server since Distillery needs a fair bit of memory to build. That is why the guide specifically allows building the release on your development (local) machine and then running the resulting release on the actual deployment machine.
So, you have two options:
Either way, I didl’t really write up anything on moving the actual resulting container/image to your droplet. That’s probably possible, but I’m not well versed in it.
The way I do it is that I just build the release and immediately run it on the droplet itself because mine can handle it. So, I just git pull
the code onto the droplet, run build.sh
to build the release (a tarball will be generated in the _build
folder), and then run docker-compose up
to run your app! Basically, that’s how iI do it and it looks like that’s what you tried also. Really, its fine for a basic setup. Again, Docker definitely has ways of pushing the built image up from your dev machine and then pulling it down onto the droplet to deploy it, but I haven’t looked into it much yet.
Let me know if you have any questions!
Using Ubuntu or any other normal Linux distro is not the best approach, once you are running containers you want to use an Operating system specific for that… I said CoreOS because is very easy to deploy in Digitall Ocean.
Another alternative is to use SmarOS but not sure id Digital Ocean has already templates to build droplets for it.
Doing this just for fun is ok, but for real production use cases should be avoided.
I definitely will read you approach and try to see in what differs from mine so that I can learn and improve my knowledge about build Elixir releases.
When developing in Elixir I use a 100% Docker workflow with this Elixir Docker Stack.
When I want to deploy to my server I just build the release with this Docker Image in my laptop and then I push the Docker Image to the Gitlab private registry for containers. Afterwards in my CoreOs server I just use a Docker Compose file to run the Elixir App with volumes mapping to the host for secrets and persistence.
By now this Elixir Docker Stack is a work in progress and my releases are not for real production use cases, they are just for fun and learning purposes.
My future goal is to build and release from a Gitlab CI pipeline using the Gitlab Container Registry and maybe their Auto DevOps workflow that will include the use of Kubernetes.
For now my priority is to learn to properly code in Elixir and leverage the OTP way of doing things, thus I will leave this approach of auto deployments for later, but I am keening to learn more about deploying Elixir Apps, thus I hope that more developers jump in and share their way of doing it.
smartos is more like a hypervisor rather than an os, so there is little chance digitalocean would ever be able to support it.
thus I hope that more developers jump in and share their way of doing it.
Currently, I build the release in either docker or vagrant for several os/cpu architectures, then push it to a cloud storage, then spin up a vm in any cloud provider via terraform with a shell script which downloads the release and starts it up. Later, I’ll start building the releases in the cloud to avoid running vagrant and docker on my laptop.
I used kubernetes for a project and found it way too complicated for my current use cases, so I tend to just use either erlang’s distribution mechanisms or lasp/partisan over tls. So the life-cycle of my deployment is like this:
One big downside of kubernetes for me is that it seems to be design to work within a single datacenter, whereas I usually deploy over several.
I know about the existence of SmartOS but not had time to read too much or even try it… Good to know it cannot be used in same fashion of CoreOS.
I think I will never go down this path… currently doing it on my laptop just for learning purposes but after will do it in a CI pipeline.
Definitely using Kubernetes is not tailored for simple use cases and pet Apps, unless as a learning Playground for later real usage in more complicated deployments where Kubernetes may shine.
It is possible to deploy to multiple zones in the cloud, please see https://kubernetes.io/docs/admin/multiple-zones/
after will do it in a CI pipeline.
I meant that homogeneous apps like mine (which can use only erlang) don’t really have any need for kubernetes and/or docker. Also, I don’t see the need for a consensus (kubernetes uses etcd) in my deployments, and a bit afraid that it would only slow down the system when I start adding more data centers.
It is possible to deploy to multiple zones in the cloud, please see > https://kubernetes.io/docs/admin/multiple-zones/
Yeah, I’ve seen that, but that’s much more complicated than my current approach (with client-server partisan topology) and wouldn’t actually work for my use-case (this approach would only work for multiple zones, not multiple datacenters). For multiple datacenters, I’d need to use etcd or consul to connect the different kubernetes clusters, which would be much slower than just using partisan over tls.
Don’t get me wrong, kubernetes is fine, it’s just not as good as a tailored solution, which is, thankfully, quite possible and not that difficult with erlang. Setting up my current pipeline (and learning a bit about distributed computing along the way) took me less time than to learn how to properly use and setup a single kubernetes cluster.
No I don’t… Kubernetes is still a goal to achieve in my DevOps aspirations
I believe that for Elixir/Erlang the use of Kubernetes may not be the best solution for the majority of us that do not have large applications and that current solutions in the OTP ecosystem will suffix. After all the BEAM supports much more workload, in orders of magnitude, than other traditional VMs, thus delaying the need for complex deployment systems