Date: Thu, 30 May 2019 20:55:28 +0000 From: Grzegorz Junka <list1@gjunka.com> To: freebsd-erlang@freebsd.org Subject: Re: Deploying program on erlang runtime 21 Message-ID: <80e2288e-c7f8-f5f8-7551-65b2433b4201@gjunka.com> In-Reply-To: <18BC9005-CDE4-43A8-8EC0-F4D7556E20EC@getsomewhere.net> References: <4259DD93-00E2-4EB6-A1C3-DC4CBCEDD34C@getsomewhere.net> <36da7161-b304-4456-8027-d12eba2ac217@www.fastmail.com> <18BC9005-CDE4-43A8-8EC0-F4D7556E20EC@getsomewhere.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30/05/2019 20:48, Joe Love wrote: >> On May 30, 2019, at 7:50 AM, Dave Cottlehuber <dch@skunkwerks.at> wrote: >> >> On Wed, 29 May 2019, at 20:31, Joe Love wrote: >>> Hi, >>> >>> I’ve been trying to wrap my head around creating my Elixir-based >>> projects on my client workstations (which are not freebsd) and >>> deploying them to a FreeBSD server using the erlang-runtime-21 package. >>> >>> I think I’m a bit lost somewhere on it, and am hoping to get some guidance here. >>> >>> I’ve created my project on my mac. I’ve added Distillery (per many >>> suggestions & guides). If I understand everything correctly, I can’t >>> include ERTS, as that’s the part which is compiled based on the host >>> OS. Therefore, I modified my Distillery config to not include ERTS in >>> the production build, and then ran `mix release --env=prod`. >>> >>> I uploaded the resulting _build/dev/rel/myproject to the FreeBSD server >>> which has erlang-runtime-21 on it. >>> I set my path to include /usr/local/lib/erlang21/bin, added >>> ERTS_LIB_DIR = /usr/local/lib/erlang21/erts-10.3 and tried to run it. >>> Apparently I have erts-10.1 on my machine and the server had erts-10.3, >>> so it seems that that also needs to match. >>> >>> So, given all of this, I remember being told that while the lang/erlang >>> port was older, that I could always use the runtime ports, and things >>> would work. Can someone fill me in on how they're supposed to work? >>> It seems like things are more intricate regarding running beam-vm-based >>> programs on a different machine than that you’re building it on. >>> >>> Thanks, >>> -Joe >> Hey Joe, >> >> welcome. I deploy to FreeBSD with Elixir & distillery 2.0 without any issues. >> The simple fix is to move off OSX to FreeBSD like I did and then this problem >> goes away ;-). >> >> TLDR: build your releases on the same OS+package as your deploy target. >> >> If you unpack the .tar.gz that distillery creates, you'll see inside a ./releases/ >> folder. the RELEASES and *.rel and start_erl.data all specify explicit versions >> of runtime and related libraries. If your Mac-based OTP release is *exactly* >> the same as the FreeBSD one, *and* you have no NIFs, then it's possible >> to get this working. >> >> IMHO getting cross-compilation etc sorted isn't worth it when you can >> build in a jail anyway. I then create FreeBSD packages from the distillery >> release, and simply pkg-install those. >> >> I'll write this up and post a link to it tomorrow on how to do this, it's >> too long to fit in an email. >> >> details: >> >> 1. always build releases on the same OS+arch+BEAM+packages as you >> intend to deploy to. Cross-building is possible but surprisingly tricky. >> If the patch versions are different, stuff may not start. >> >> erts (Erlang RunTime System) has different patch levels and point releases. >> The OTP 21 runtime on your Mac may not be the same one you're deploying >> to. >> >> The FreeBSD ones have just this week been updated and moved to a much >> easier-to-update system (thanks olgeni@ ) so we should be staying pretty >> up to date with official releases now. We have OTP21,22 and Elixir 1.8.2 >> >> Right now, that's 21.3.8.2 which has different modules from the original >> OTP 21.0 shipped months ago - >> asn1, crypto, kernel, ssl, stdlib, & more have all evolved. Your mac >> built release probably won't have the same modules on it, and the release >> is *very* specific about what it requires. >> >> 2. if you have NIF modules (native C code) then this definitely won't work >> as the linked libraries aren't remotely compatible. >> >> 3. Every time the lang/erlang-* port is updated, you'll need to rebuild your >> application (if you're not including erts). >> >> A+ >> Dave > Hi Dave, > > Thanks for following up. I look forward to reading any sort of write-up you might make on the subject, but I get the short answer: “Compile it on FreeBSD.” > > I know I’ve seen the emails on the mailing list regarding updating lang/erlang to 21, so I’ll get my ports tree updated and go from there. > > Thanks, > -Joe Hi Joe, I used to be on a project where Erlang was running in production on a Solaris box and it was being patched with beam files compiled on Ubuntu. In general beam files should be portable across systems as long as the same major version is used. In your example beam files compiled on 10.1 should run on 10.3 and vice versa. However, I am not sure what happens when you throw "mix" into the mix. Surely ERTS isn't portable. In general anything that is compiled to C isn't portable and anything that compiles to BEAM should be portable. But any tooling or additional files may or may not be portable depending on how they have been written. For example, OTP releases produced with reltools will not be portable since they would include all the stuff that is compiled to C. Not sure how mix produces its releases though. I am running FreeBSD as desktop and do all my development on it. Same as Dave, I would recommend you to try to develop or at least compile on FreeBSD as the safest and easiest route. GrzegorzJ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80e2288e-c7f8-f5f8-7551-65b2433b4201>