[erlang-questions] How do you go to production?

Tue Apr 16 22:24:46 CEST 2019

Hi Lloyd,

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

operator.

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 
week.

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.

Regards,

Dieter

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,
>
> Lloyd
>
> -----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?
>
>
> Hi,
> 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 
> sasl.
> Unit testing was done in EUnit.
>
> This was my first project where I used erlang, and the learning curve 
> was quite gentle.
> Kind regards,
> Dieter
>
> Am So., Apr. 14, 2019 11:20 schrieb Max Lapshin <max.lapshin@REDACTED>:
>
>     Hi.
>     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:
>     https://github.com/flussonic/epm
>     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:
>     https://gist.github.com/maxlapshin/01773f0fca706acdcb4acb77d91d78bb
>     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
>     branch)
>     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:
>     https://github.com/flussonic/ssh-proxy
>     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
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190416/7ad3bae5/attachment.htm>