4 ms·

I remember being a reviewer for an Elixir book where the first chapter was listing the pros and cons of Elixir, and one of the cons was: it's kind of hard to m

by dudul 5y ago

I remember being a reviewer for an Elixir book where the first chapter was listing the pros and cons of Elixir, and one of the cons was: it's kind of hard to manage deployment of Elixir applications. My feedback was "hum, that's kind of a turn off for someone trying to learn the language/tech no?" I think the community has been looking for something for a while now and is iterating (too?) quickly. There was erlang releases, there was distillery, now it's elixir releases. There are different ways of configuring in production. It goes a little too fast to keep up with to be honest.

dnautics 5y ago
too fast? I was using Elixir releases two jobs ago.
1_player 5y ago
It took me 1 hour to convert a production app from Distillery to native releases when Elixir 1.9 released 2 years ago. And deployment in 2021, whatever the language, is best served with containers. Elixir is not harder to deploy than a Django or Node app. In fact, releases and post-deploy ops are pretty well documented: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html Phoenix also has an example multi-stage Dockerfile which is fine for 99% use cases: https://hexdocs.pm/phoenix/releases.html https://hexdocs.pm/phoenix/releases.html
- dnautics 5y ago
  > And deployment in 2021, whatever the language, is best served with containers. ...in 2020 I deployed to bare metal servers. Mix released a gzip to S3 and pulled the artifact down, systemctl restart dnautics_service. You're making me feel like some sort of dinosaur.
  - bfbelmont 5y ago
    Bare Metal / Containers / VM It's all about managing your dependency chain, and how much variation of environment you're willing to accept. You don't need to feel like a dinosaur if what you're doing is principled and reasonable. There's no one size fits all.
    - dnautics 5y ago
      Haha we bought these servers for 5k, very op, but since we had a rack full of HW (that this one blade was managing) anyways, the server price/power consumption for a 1U was a drop in the bucket. Very strange world. I think the server was at 10% CPU consumption, and we didn't bother doing the erlang "turn off IO polling for modern cloud operating systems" option.
    - deleted 5y ago
      [deleted]
  - aparks517 5y ago
    Don't let the kids get you down. My deployment scripts look something like this: rsync --rsync-path=/usr/bin/openrsync -r --delete config lib mix.exs mix.lock priv server:my_project ssh server "tmux respawn-window -t my_project:1 -k" It's only weird if it doesn't work, right?
    - daniellarusso 5y ago
      I also use tmux as part of my deploy process. ;)
    - deleted 5y ago
      [deleted]
  - heavyset_go 5y ago
    If you're already using systemd, you can use systemd-nspawn to launch your service in a container and nothing would change in your workflow.
- sergiomattei 5y ago
  I agree! As a learning project, I wrote a small service[0] that reports data from our solar panels to InfluxDB every second. I thought deploying would be a pain. It was really painless: a matter of cloning on the home server, running ‘mix release’ and pointing a systemd unit to the start script it generated. It was a pleasant surprise, especially coming from the Django world where anything deployment related would be a day’s work. [0] https://github.com/matteing/mate3s-influx-reporter https://github.com/matteing/mate3s-influx-reporter
pmontra 5y ago
It's going fast because the original ways were (euphemism) sub optimal. Example: compiling configuration into a release was clearly wrong based on my experience with other languages. A small mistake and another run through CI/CD with production down vs edit a configuration file and restart? Ouch. Maybe inevitable with a lot of servers but very wrong for a single server application.

by dudul 5y ago

dnautics 5y ago

too fast? I was using Elixir releases two jobs ago.

1_player 5y ago

It took me 1 hour to convert a production app from Distillery to native releases when Elixir 1.9 released 2 years ago. And deployment in 2021, whatever the language, is best served with containers. Elixir is not harder to deploy than a Django or Node app. In fact, releases and post-deploy ops are pretty well documented: https://hexdocs.pm/mix/Mix.Tasks.Release.html https://hexdocs.pm/mix/Mix.Tasks.Release.html Phoenix also has an example multi-stage Dockerfile which is fine for 99% use cases: https://hexdocs.pm/phoenix/releases.html https://hexdocs.pm/phoenix/releases.html

dnautics 5y ago
> And deployment in 2021, whatever the language, is best served with containers. ...in 2020 I deployed to bare metal servers. Mix released a gzip to S3 and pulled the artifact down, systemctl restart dnautics_service. You're making me feel like some sort of dinosaur.
- bfbelmont 5y ago
  Bare Metal / Containers / VM It's all about managing your dependency chain, and how much variation of environment you're willing to accept. You don't need to feel like a dinosaur if what you're doing is principled and reasonable. There's no one size fits all.
  - dnautics 5y ago
    Haha we bought these servers for 5k, very op, but since we had a rack full of HW (that this one blade was managing) anyways, the server price/power consumption for a 1U was a drop in the bucket. Very strange world. I think the server was at 10% CPU consumption, and we didn't bother doing the erlang "turn off IO polling for modern cloud operating systems" option.
  - deleted 5y ago
    [deleted]
- aparks517 5y ago
  Don't let the kids get you down. My deployment scripts look something like this: rsync --rsync-path=/usr/bin/openrsync -r --delete config lib mix.exs mix.lock priv server:my_project ssh server "tmux respawn-window -t my_project:1 -k" It's only weird if it doesn't work, right?
  - daniellarusso 5y ago
    I also use tmux as part of my deploy process. ;)
  - deleted 5y ago
    [deleted]
- heavyset_go 5y ago
  If you're already using systemd, you can use systemd-nspawn to launch your service in a container and nothing would change in your workflow.
sergiomattei 5y ago
I agree! As a learning project, I wrote a small service[0] that reports data from our solar panels to InfluxDB every second. I thought deploying would be a pain. It was really painless: a matter of cloning on the home server, running ‘mix release’ and pointing a systemd unit to the start script it generated. It was a pleasant surprise, especially coming from the Django world where anything deployment related would be a day’s work. [0] https://github.com/matteing/mate3s-influx-reporter https://github.com/matteing/mate3s-influx-reporter

pmontra 5y ago

It's going fast because the original ways were (euphemism) sub optimal. Example: compiling configuration into a release was clearly wrong based on my experience with other languages. A small mistake and another run through CI/CD with production down vs edit a configuration file and restart? Ouch. Maybe inevitable with a lot of servers but very wrong for a single server application.