What do you need from a deployment tool?

In general an ERTS needs to work on the same version of erlang as it was built for.

In addition, a lot of libraries compile code for NIF’s or Ports or so, and those are quite often platform dependent.

1 Like

I would like to see one deployment tool that made a bunch of assumptions about how deployment was going to be done. So many assumptions that most of the more capable developers here would find it restrictive. It would act as a starting point.

When it did not fulfil some users requirements another solution can be created or this original tool extended where possible.
I am working on something myself with the following assumptions.

  • Docker is used
  • Configuration is with ENV variables
  • Clustering will have to deal with dynamic ip addresses

I recently posted an intro talk to setting up projects, there is a follow up in the works which is more thorough an covers a decent deployment solution.

Agreed. This problem would be far less if starting from any sensible set of defaults and expanding in a pragmatic fashion.

Something I tripped up on myself. Always using env is restrictive but works for a lot of cases, I have gone so far as to remove config.exs from my project generator so I have only one way to manage runtime config.

I’ve managed to get starting up a new Elixir project down to 3 commands, without even having Elixir installed (CAVEAT on a machine with docker. My target is people interested in the polyglot nature of microservices). My hope is that with a few more command a multi node deployment on production machines can be created.

I will probably assume deployment to kuberneties. I may even assume one particular platform, perhaps gigalixir. I hope this can be expanded in time, but is not something to start with.

2 Likes

If we assume k8s one could probably come up with a way to build a Helm chart at least for Phoenix apps and it will be a 2 command deploy. Now k8s is a fairly strong req.

1 Like

Any idea why this is not there by default? I just wasted an hour before I realized it’s not in here.

1 Like

https://github.com/phoenixframework/phoenix/pull/2499

@chrismccord said:

It’s not set for prod by default because you may want to run other tasks, for example mix ecto.migrate or even iex to debug prod and in those cases you won’t want to spin up a phoenix server.

2 Likes

I figured I should update everyone here, but I accepted an offer to join DockYard to fill the position they opened up for this. I’ll be formally starting November 3rd, and once I do I’ll be jumping into this head first.

I’ll be posting more in the forum once I have some more concrete steps fleshed out, partly to keep everyone up to date, but also as a means of gathering feedback on what’s planned. More to come later!

49 Likes

That’s awesome news - congrats! :023:

Perfect person for the job :003:

Congrats!!!

2 Likes

There is no better person for the job. Distillery and exrm are great tools, I can’t wait to see the third iteration in the family.

Congrats @bitwalker, looking forward to your updates :grinning:

2 Likes

so… it’s going to be a completely new implementation, separated from distillery? @bitwalker can you reveal something more already? :slight_smile:

6 Likes

I’ve being a bit out of touch due to moving, switching work projects and dabbling in Rust a bit. Now looking too start a new personal proj. in Elixir again was wondering are there any updates on this new tool ?

3 Likes

And then there should be a book by @josevalim and @chrismccord called “Reliably Deploying Elixir and Phoenix Applications using deployex”. :slight_smile:
(book name copied from Reliably deploying rails applications :smile: ).

Nice update about deploy tools! Thanks @bitwalker

Sounds like a big step in the right direction.

15 Likes

This is great news! I struggled with Elixir’s config vs releases myself (and my early projects used them totally wrong) and have only recently gotten into actually using releases. I sense this friction between your normal development vs deployment affects many others too, so anything that helps the situation is welcome.

As I understood it, the plan would be to have config.exs read on application init and so you could directly get env vars there? That would be sweet and save from a lot of hassle.

Brilliant update - really excited by everything you’re planning @bitwalker :023:

1 Like

Thanks for the feedback everyone! I’m glad you all like the direction :slight_smile:

More or less, to be clearer, the plan is to have Elixir’s configuration file be evaluated and pushed into the application env (i.e. which is exposed by Application.get_env/3) right after Elixir is loaded and started, and before any other applications are started. This mirrors how Mix handles things today, and would allow you to access the application env in your own application right away without having to do any of your own fetching/transformation.

Of course, that’s only true for things which use the config file, for those use cases where you need to fetch configuration from external system, say etcd, you’d still have to follow more or less the existing approach to that scenario. That said, I’m hoping to provide an extension point which allows one to extend the configuration system with custom providers, so that by the time applications start booting, all the configuration is done. I don’t know what that will look like yet, but I think it’s an important part of consolidating configuration into a single approach.

I know José is planning to move what is currently Mix.Config out of Mix and into Elixir as Application.Config, and while initially it should just mirror how Mix.Config works today, I suspect that would provide us a foundation for extension like I mentioned above.

15 Likes

Great news! Unifying Mix and OTP releases will be amazing. Any plans to tackle the process of getting your release onto servers, updating, smoke testing etc? Personally I’m happy to use language agnostic tools like ansible for such tasks, but I get the impression many devs are looking for an elixir-native solution.

1 Like

My dream deployment tool is one that would allow me to easily update a running server with git.

In simpler setups, for those small site that have yet to reach a size where they need multiple servers, the deployment server and the build server are one and the same. I would just ssh into the server do a git pull and then build the assets, digest, migrate and then restart the phoenix server.

It would be wonderful if I could just add the deployment server as a remote to the dev machine repository and then just push to that remote in order to trigger an update. Ideally, the deployment tool would have this use case in mind and would automatically do what is needed based on sensible configuration.

I don’t know what percentage of sites developed with elixir fall into this category of small, single server sites but I doubt it is a trivial percentage.

3 Likes

I have several small web projects and I find it easier to build in a vm (vagrant) or a container than on the deployment server. It can also be automated with git hooks and a shell script.

commit -> spin up a container -> build release -> push tarball -> upgrade

1 Like

Once you know how to do it, it becomes very simple but to a person that might not have all the knowledge this might look scarily complex.

I have never used vagrant. Do you have your setup described in some post? I would love to take a look.

1 Like