[erlang-questions] How do you go to production?
Tue Apr 16 22:24:46 CEST 2019
this week I am not in the office, so I can just try to do a brain dump.
The installation was quite simple, I installed a plain Ubuntu desktop,
and then extracted the erlang tar file into /opt. This is done by one or
two shell scripts.
The erlang app is started on demand by another application, which is
launched by the
So I do not have to deal with systemd (which I also do not like very
much) or the like.
My application could run as a server, but in the current use case there
is no need for that.
For the footprint of the docker container I will have to come back next
I really have no idea how big it is. In former times I have used
VirtualBoxes with snapshots
for similar tasks, but if the focus is quite narrow, a docker container
is far more easier and quicker
than a complete VM.
On 16.04.19 21:54, lloyd@REDACTED wrote:
> Hi Dieter,
> Many thanks for sharing your experience.
> Could you please outline your installation procedure? Also, the size
> of your Docker application image (RAM footprint) ? I've been
> considering LXC containers, but I'd like to test with Docker.
> All the best,
> -----Original Message-----
> From: "Dieter Schön" <dieter@REDACTED>
> Sent: Tuesday, April 16, 2019 3:46pm
> To: "Erlang-Questions Questions" <erlang-questions@REDACTED>
> Subject: Re: [erlang-questions] How do you go to production?
> here is a case from the other end of the spectrum.
> I developed a protocol converter for a satellite test system, it is
> installed on 2 (in words: two) PCs.
> For development, I used one application and rebar3. Production is just
> "rebar3 as prod tar" (From a labelled git commit).
> Testing was done on the two PCs, where I used one as the system under
> test and the other as test harness/data generator.
> I was also using wireshark and other third party tools, to prevent
> incestuous behaviour.
> To test the installation procedure I used docker, which was really
> nice. I had a blank machine in two seconds,
> where I could load and execute the installation script from the host.
> I had turnaround cycles from several seconds.
> What else.. the application is quite small. It fits into one erlang
> application. Apart from it, the release only contains the observer and
> Unit testing was done in EUnit.
> This was my first project where I used erlang, and the learning curve
> was quite gentle.
> Kind regards,
> Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin <max.lapshin@REDACTED>:
> I'm developing Flussonic for almost 10 years and we have some
> practices for packaging, deploying, running, maintainig that are
> not well known, however they are rather good for us.
> It is interesting how do other people solve this.
> At first, we do not use releases. It is because when we have
> started our long path, using of releases was not very easy.
> Couple of days ago I've tested it with rebar3 and it is really
> easier to use. Perhaps we would use releases today.
> Next: we use our own fpm script replacement for packaging. I can
> boast that it seems to be the only existing implementation of rpm
> outside of original library, however I'd better never pass this
> path again. I've written it in pre-docker era and frankly speaking
> it is a traumatic experience. However, we are using it for debian
> and it is really convenient:
> Some time ago we have switched to systemd. I personally consider
> systemd a very badly designed thing that was created without any
> discussions with existing system adminstrators. For example,
> systemd doesn't offer config validation before launch. Another
> brilliant idea is to offer libsystemd for linking into
> application. Unknown library with unknown quality. What can go
> wrong if you link it into your erlang or java application?
> Sorry, but no. We have systemd.erl:
> Use Type=notify in youdaemon.service
> After you manage to launch your erlang daemon, you need to collect
> statistics. We had to add some more linux-related tools to fetch:
> cpu usage, disk I/O usage, system ram usage (swap, etc),
> per-interface network statistics, udp errors count, nvidia card
> usage, etc.
> If this is worthy outsource, I think we can extract it.
> Our os_stat library is linked with our in-erlang pulsedb library.
> We try to maintain as less dependencies as possible, so we collect
> all ticks from monitoring tools inside erlang library pulsedb:
> https://github.com/pulsedb/pulsedb (maybe should update public
> It can save several thousands metrics with one tick per 1-3 seconds.
> Support is an important part of our business, because customers
> cannot just launch software, they often need help. We have many
> people in support staff and I do not want to manage their own
> public ssh keys on customer's servers. So we have written an ssh
> proxy: system that login to customer server with one private key
> and allow support guy to use his own key:
> All these things are rather useless for development and many of
> them are not required for in-house development, however it is hard
> to live without them when you sell software.
> What is your experience with such things that standard erlang lacks?
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions