WIP: Docker-ng (alpine) #1919

0xdevalias · 2017-03-02T21:36:09Z

This is a WIP to track my efforts on docker-ng (#1874).

FYI, I fully expect this build to fail currently, and am making no efforts to fix that side of things till it's all working well locally. May need to cherry pick/refactor the history depending on how #1876 / etc go.

Would love any comments/feedback/testing/etc.

Builds from alpine image supporting therubyracer (usualoma/ruby-with-therubyracer:2.4.0-alpine)
Ruby 2.4 (may need to wait on Support Ruby >=2.4 #1876)
Currently setup to be tested against mysql:8.0
Seems to have issues with utf8m4
May not have the full binary dependencies installed for all gems at runtime
Unicorn not currently linked to a reverse-proxy
See ./compose-huginn-ng-mysql.sh
- ./compose-huginn-ng-mysql.sh build huginn
- ./compose-huginn-ng-mysql.sh run —user="root" huginn sh

Sizing

Currently includes git as a runtime dependency, unsure if needed (it’s heavy.. ~16mb)
Builds to an image ~366 MB (by docker images)
usualoma/ruby-with-therubyracer:2.4.0-alpine is ~115mb of that
For comparison, current 'legacy' docker builds (ubuntu) are:
- cantino/huginn ~884 MB
- cantino/huginn-single-process ~690 MB

See gimite/google-drive-ruby#167 (comment)

* Builds from alpine image supporting therubyracer (usualoma/ruby-with-therubyracer:2.4.0-alpine) * Ruby 2.4 * Currently setup to be tested against mysql:8.0 * Seems to have issues with utf8m4 * May not have the full binary dependencies installed for all gems at runtime * Unicorn not currently linked to a reverse-proxy * Currently includes git as a runtime dependency, unsure if needed (it’s heavy.. ~16mb) * Builds to an image ~366 MB (by docker images) * usualoma/ruby-with-therubyracer:2.4.0-alpine is ~115mb of that * See ./compose-huginn-ng-mysql.sh * ./compose-huginn-ng-mysql.sh build huginn * ./compose-huginn-ng-mysql.sh run —user=“root” huginn sh

dsander

Very cool @alias1! I did not expect the image to be that much smaller.

Sadly the build failed for me:

tep 11/16 : RUN set -ex     && bundle update rails
 ---> Running in acea035a250e
+ bundle update rails
The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32. To add those platforms to the bundle, run `bundle lock --add-platform mingw, mswin, x64_mingw`.
Fetching gem metadata from https://rubygems.org/......
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
You have requested:
  json ~> 1.8.5

The bundle currently has json locked at 1.8.3.
Try running `bundle update json`

If you are updating multiple gems in your Gemfile at once,
try passing them all to `bundle update`
The command '/bin/sh -c set -ex     && bundle update rails' returned a non-zero code: 7

dsander · 2017-03-03T16:57:05Z

Gemfile

@@ -117,7 +126,7 @@ gem 'mini_magick'
 gem 'multi_xml'
 gem 'nokogiri'
 gem 'omniauth', '~> 1.3.1'
-gem 'rails', '~> 5.0.1'
+gem 'rails', '~> 5.0.2'


I think we should update and test the rails upgrade in a separate PR.

Absolutely agree. Not sure this will end up being the final PR as is, might refactor the commit history or something in the end. I tend to test things as I go and commit in small chunks. Bumped this one (i think) due to a requirement in one of the other gems I bumped.

dsander · 2017-03-03T17:01:27Z

Gemfile

@@ -192,14 +201,22 @@ ENV['DATABASE_ADAPTER'] ||=
    'mysql2'
  end

-if_true(ENV['DATABASE_ADAPTER'].strip == 'postgresql') do
-  gem 'pg', '~> 0.18.3'
+if_true(ENV['DATABASE_ADAPTER'].strip == 'postgresql' || !!ENV['INSTALL_ALL_DBS']) do


That's a good idea! I bet the additional space needed in the image is not much compared to the improved startup time? Maybe rename it to INSTALL_ALL_DATABASE_ADAPTERS?

I haven't checked to any great level of detail, but I think it was pretty minimal, maybe a few mb? The main difference comes from needing all of the dev libraries for each DB to compile them, but initial testing seems to imply that we can remove them again once they're compiled, so long as we have the runtime libs installed (much smaller)

Yeah, can definitely change it to INSTALL_ALL_DATABASE_ADAPTERS.

dsander · 2017-03-03T17:03:46Z

docker/Dockerfile.ng

@@ -0,0 +1,213 @@
+FROM usualoma/ruby-with-therubyracer:2.4.0-alpine


Can you remake this image based on ruby 2.3? I think it would make this PR a bit lighter and separate it from the ruby upgrade in #1876. I would also like to see how much work is required to switch ruby versions in alpine as we will need to move to ruby 2.4.x and 2.x eventually.

Currently, no. The only image that exists is built on 2.4

That said, can definitely investigate whether the same technique would work on a 2.3.x build, and if so, we can definitely try it. Would be awesome to isolate the changes/differences required, and give us a far better platform for compatibility checking.

Have opened an issue (usualoma/ruby-with-therubyracer#2) to investigate this.

@usualoma is an absolute legend. Pushed 2.2.x/2.3.x images already!

@dsander Will check them out this evening/when I get a spare second to work on this again.

Awesome, sounds great!

dsander · 2017-03-03T17:05:58Z

docker/Dockerfile.ng

+#  libmysqlclient-dev libpq-dev libsqlite3-dev \
+#  ruby2.3 ruby2.3-dev
+
+# TODO: Put together a little script that will easily parse out all the .env.example lines to copy into here


I like the idea of dropping the .env file in the docker image. We need to decide how we handle backwards compatibility, the current solution with .env` sometimes requires double escaped strings which will probably not work without converting the values here.

Maybe we can put together a little script to 'update' a double escaped .env file? Or maybe just an 'upgrading' type 'breaking changes' document could explain this process.

docker-compose has built in support for using .env-styled files, and then you can override it further in the environment key:

env_file: - ../.env environment: # These values override the env_file DATABASE_HOST: db #etc

dsander · 2017-03-03T17:07:22Z

docker/Dockerfile.ng

+
+# TODO: Need to tune the .dockerignore, or prevent some things being copied here
+#  eg.
+#    Gemfile.lock has caused issues in testing


What were those issues? I think the Gemfile.lock is essential to ensure the image uses our locked gem version.

Absolutely going to keep the Gemfile.lock for final production version. The issues were more around me bumping gems in the Gemfile, not updating the file on my bare system, then building the docker image; it wasn't passing through the Gemfile.lock in the initial stages (commented out), so the initial gem installs work, but then later when it adds the full huginn source, the Gemfile.lock is added, and so it won't start properly.

So, the main issue is laziness during testing ;p

0xdevalias · 2017-03-05T22:26:50Z

@dsander Off to a promising start for sure! But we won't count our chickens just yet. There may be additional runtime dependencies that are needed which might bump the image size up more.

Will address most of your comments inline, but the build failing is related to the Gemfile.lock thing.

This reverts commit aa481c8.

This reverts commit eb0cb13.

This reverts commit 62f59f6.

This reverts commit ee7f418.

0xdevalias · 2017-03-08T07:57:39Z

I'll go back and clean up the history once this is in a working state.

@dsander Should be able to build now, and with less 2.4.x weirdness mixed in. Exposing huginn on 3000, but it didn't seem to be loading resources. ./compose-huginn-ng-mysql.sh

huginn_1  | [b36bf86b-fca8-4575-8864-d0c598dd6d51] Started GET "/images/" for 172.18.0.1 at 2017-03-07 23:51:59 -0800
huginn_1  | [b36bf86b-fca8-4575-8864-d0c598dd6d51]
huginn_1  | [b36bf86b-fca8-4575-8864-d0c598dd6d51] ActionController::RoutingError (No route matches [GET] "/images"):
huginn_1  | [b36bf86b-fca8-4575-8864-d0c598dd6d51]
huginn_1  | [b36bf86b-fca8-4575-8864-d0c598dd6d51] config/initializers/silence_worker_status_logger.rb:3:in `call'

Also maybe some DB errors

db_1      | 2017-03-08T07:58:19.985072Z 7 [Note] Aborted connection 7 to db: 'huginn' user: 'huginn' host: '172.18.0.3' (Got an error reading communication packets)

dsander · 2017-03-09T14:12:14Z

@alias1 Nice, it got a bit bigger for me, but still a lot smaller then the current image.

Exposing huginn on 3000, but it didn't seem to be loading resources. ./compose-huginn-ng-mysql.sh

It's probably missing the RAILS_SERVE_STATIC_FILES environment variable. The database errors look normal they are probably from rake db:migrate or some other task that is done before starting the application server.

I am wondering if we can keep most of the old script structure and the init` file for now. By "only" changing the OS and dependencies we would not need to worry about the initialization process because I assume bash in alpine works the same it does in ubuntu.

Putting the docker file in docker/single-process/Dockerfile should also make it build automatically for this PR.

0xdevalias · 2017-03-09T19:47:48Z

I'll have a look over the scripts again when i get chance. The intention was to encode all of the setup steps into the dockerfile itself, and should largely be using the same init script, but i may have missed some bits.

Note to self: Nice way of handling the DB linking https://github.com/docker-library/redmine/blob/master/docker-entrypoint.sh#L32

dsander · 2017-03-10T23:14:19Z

I have seen two different patterns of docker image builds, one is putting everything in the Dockerfile and the other is to put everything that does more then adding or executing a binary into a bash script. I kept the latter because I find it easier to read and modify the bash code when it is in a file with syntax highlighting.
Is there a benefit of having it all in the Dockerfile?

0xdevalias · 2017-03-11T01:14:45Z

I'm no expert by far, but I don't think there's a huge difference between the two. I suppose adding the script file and running it leaves 'clutter' in the container, unless you're explicitly removing it again. May have to add extra layers (e.g. Copy, then run) My main motivation was following the pattern of a bunch of the official files, and others I've seen, and far more that I've come across seem to stick to the 'all in dockerfile' approach. Then personally, it sort of feels a bit cleaner having everything explicitly detailed within the one file. But that's not really a strongly evidenced opinion one way or another.

0xdevalias · 2017-03-19T21:29:07Z

Ok.. had a quick look at the old scripts.. seems I failed to read/copy from them properly. Also.. time gets away so quickly..

Add asset compilation steps/etc from ./legacy/scripts/setup to dockerfile

0xdevalias · 2017-04-09T02:54:24Z

Thinking some more about this.. I wonder if we want/need to keep the ubuntu base image, as opposed to a debian based one? That way we could use the official ruby docker image

…supporting scripts

dsander · 2017-04-09T10:08:49Z

I'm not convinced if we'll be able to get it to a running state at the moment (till some upstream issues are fixed

That's a bummer, but kind of resembles my experiences with complex applications on alpine. The main issue is still libv8?

I figured that once properly setup, they would be minimal effort to maintain, and would give people the option in case they don't want the restrictions of an alpine-based environment.

Not sure about this, I think if we add an alpine image it should support everything the ubuntu/debian based image supported and then there should not be a need to keep the old images. Even if the setup is very clean it still adds environments that we need to support.

I suppose it could satisfy both?

Neat, I have no experience with using docker in development so I don't know how one typically sets uses it.

Thinking some more about this.. I wonder if we want/need to keep the ubuntu base image, as opposed to a debian based one? That way we could use the official ruby docker image

I don't see why we need to keep the ubuntu base image. It would probably add some more layers but the same time reduce the amount of data to be downloaded when our layer cache is invalidated or fails (which seems to happen sometimes on travis).

huginn#1959 Might help with huginn#1919

0xdevalias · 2017-04-10T09:47:45Z

That's a bummer, but kind of resembles my experiences with complex applications on alpine. The main issue is still libv8?

I believe this is the main issue to watch, as far as therubyracer is concerned: rubyjs/therubyracer#378

Not sure about this, I think if we add an alpine image it should support everything the ubuntu/debian based image supported and then there should not be a need to keep the old images. Even if the setup is very clean it still adds environments that we need to support.

It does add extra environments to support.. but then I would think that we would still want to support 'normal' OS's, for people who aren't going to be using the docker images. And I think the overhead of building the extra image or so would be minimal.

Neat, I have no experience with using docker in development so I don't know how one typically sets uses it.

I suppose we'll find out! :)

I don't see why we need to keep the ubuntu base image. It would probably add some more layers but the same time reduce the amount of data to be downloaded when our layer cache is invalidated or fails (which seems to happen sometimes on travis).

nods that makes sense. Well.. as a proof of concept I think i'll work to convert the current images to the 'new dockerfile layout' anyway (since it's halfway done). If nothing else, it should prove that the new layout is sane.

@cantino Do you have any strong feelings one way or another around keeping/ditching the ubuntu image?

cantino · 2017-04-12T08:36:22Z

I don't have enough Docker experience to have an opinion on this.

0xdevalias · 2017-04-12T22:40:29Z

It's not really a docker question as much as a platforms people can run in docker question.

I'm kind of heavily leaning towards the fact that we should have an image for all of our supported platforms though. If for no other reason than making testing trivial.

dsander · 2017-04-13T19:55:42Z

I'm kind of heavily leaning towards the fact that we should have an image for all of our supported platforms though. If for no other reason than making testing trivial.

Not sure how much we would gain from it. The docker images are differing from the manual installation quite a bit. We could ensure that all gems install properly and the processes start, but I can't remember the last change that broke anything like that.
I think Vagrant would be better suited to test the actual installation on different operating systems.

0xdevalias · 2017-04-13T22:09:11Z

Hrmm.. thats probably fair. When you say it's differing from the manual install processes, I wonder by how much/in what ways? Just due to docker quirks (eg. separated DB/huginn install/etc), or due to some process that we could better align between the two install methods?

dsander · 2017-04-15T09:15:47Z

The main difference is that the manual installation uses runit to start the Huginn processes, which causes the majority of debug reports (mostly due to some package oddity or other installed packages causing incompatibilities).

Skarlso · 2017-05-10T04:02:54Z

@alias1 Seems like the rubyracer isn't maintained any longer. :/

0xdevalias · 2017-05-10T07:31:33Z

@Skarlso Oh? What makes you say that?

Skarlso · 2017-05-10T07:36:50Z

@alias1 Mainly because of the lack of responses and significant commits, or any kind of change around the PRs.

But most likely, because of this comment for example four months ago:

It is true that a lot of deadlock issues will be solved with a 1.0 release. However, I have stalled out a bit because I no longer use therubyracer daily.
I'm currently looking for somebody to help push it over the finish line.

And of course there is this, submitted in February:

sstephenson/execjs#205

0xdevalias · 2017-05-10T07:57:29Z

Interesting, thanks for pointing it out.

@dsander Any thoughts on this? Is there another way we could support the features Huginn needs without therubyracer? A friend said he was able to use node directly these days, but not quite sure what features he was using.

dsander · 2017-05-10T08:46:28Z

@alias1 I don't think we need therubyracer in particular, but don't think calling node directly would work due to the methods are are exposing to the JavascriptAgent.

Apart from the various compilation problems I am not aware of any issues that are related to rubyracer in Huginn.

huginn#1959 Might help with huginn#1919

baip · 2018-05-25T08:04:56Z

There seems to be a recipe for therubyracer: see Lesson 1 here.

huginn#1959 Might help with huginn#1919

0xdevalias · 2024-03-28T02:41:41Z

Super outdated + abandoned

0xdevalias added 10 commits March 1, 2017 07:54

Fix google-api-client to <0.9. It introduced breaking changes.

ee7f418

See gimite/google-drive-ruby#167 (comment)

Update google-api-client to latest

62f59f6

Update json gem to run on ruby 2.4

eb0cb13

Add support to Gemfile to build all db gems

9caa525

Improve Gemfile checks around missing files + warning messages

a45d608

Fix link in the single-process README

aa00510

Update DB gems

ffa227a

Move legacy docker files

8baddb3

Bump rails gem to 5.0.2

aa481c8

0xdevalias self-assigned this Mar 2, 2017

0xdevalias added the in-development label Mar 2, 2017

0xdevalias added this to the Deployment should be simple and repeatable milestone Mar 2, 2017

dsander reviewed Mar 3, 2017

View reviewed changes

0xdevalias added 9 commits March 6, 2017 09:32

Rename env INSTALL_ALL_DBS -> INSTALL_ALL_DATABASE_ADAPTERS

fe47d2f

Revert "Bump rails gem to 5.0.2"

3c9b82c

This reverts commit aa481c8.

Unbump db gems

6b8fdc5

Revert "Update json gem to run on ruby 2.4"

e0ef0b2

This reverts commit eb0cb13.

Revert "Update google-api-client to latest"

deb486b

This reverts commit 62f59f6.

Revert "Fix google-api-client to <0.9. It introduced breaking changes."

629304b

This reverts commit ee7f418.

Bump therubyracer to v0.12.3

92dc15a

Switch back to ruby 2.3 and use the Gemfile.lock again

f18a670

Improve how we handle unicorn config

2a24052

0xdevalias added 3 commits April 9, 2017 12:40

Move alpine files into their own folder

8f564c3

Rename init.ng -> huginn-entrypoint.sh

85069a0

Fix alpine compose

559c004

0xdevalias mentioned this pull request Apr 9, 2017

Replace therubyracer with execjs (if possible) #1959

Closed

0xdevalias added 2 commits April 9, 2017 18:39

Refactor docker single-process (ubuntu) into the new format + update …

5d34987

…supporting scripts

Refactor docker single-process compose files to new style

46e81ec

dsander added a commit to dsander/huginn that referenced this pull request Apr 9, 2017

Replace therubyracer with mini_racer

e394f48

huginn#1959 Might help with huginn#1919

dsander mentioned this pull request Apr 9, 2017

Replace therubyracer with mini_racer #1961

Merged

dsander added a commit to dsander/huginn that referenced this pull request Apr 9, 2017

Replace therubyracer with mini_racer

8bc8a4b

huginn#1959 Might help with huginn#1919

dsander added a commit to dsander/huginn that referenced this pull request May 21, 2017

Replace therubyracer with mini_racer

b1c4e5a

huginn#1959 Might help with huginn#1919

dsander added a commit to dsander/huginn that referenced this pull request Jan 24, 2018

Replace therubyracer with mini_racer

d49f939

huginn#1959 Might help with huginn#1919

dsander added a commit to dsander/huginn that referenced this pull request Oct 23, 2018

Replace therubyracer with mini_racer

7dae4b5

huginn#1959 Might help with huginn#1919

dsander added a commit to dsander/huginn that referenced this pull request Apr 17, 2019

Replace therubyracer with mini_racer

287e1f1

huginn#1959 Might help with huginn#1919

MarioRicalde mentioned this pull request Aug 9, 2023

Issues, Pull Requests and Milestones Cleanup (housekeeping) #3306

Open

0xdevalias closed this Mar 28, 2024

		@@ -0,0 +1,213 @@
		FROM usualoma/ruby-with-therubyracer:2.4.0-alpine

WIP: Docker-ng (alpine) #1919

WIP: Docker-ng (alpine) #1919

Conversation

0xdevalias commented Mar 2, 2017 • edited Loading

Sizing

dsander left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xdevalias Mar 5, 2017 • edited Loading

Choose a reason for hiding this comment

0xdevalias Mar 6, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

0xdevalias commented Mar 5, 2017

0xdevalias commented Mar 8, 2017 • edited Loading

dsander commented Mar 9, 2017

0xdevalias commented Mar 9, 2017 • edited Loading

dsander commented Mar 10, 2017

0xdevalias commented Mar 11, 2017 via email • edited by cantino Loading

0xdevalias commented Mar 19, 2017 • edited Loading

0xdevalias commented Apr 9, 2017

dsander commented Apr 9, 2017

0xdevalias commented Apr 10, 2017 • edited Loading

cantino commented Apr 12, 2017

0xdevalias commented Apr 12, 2017

dsander commented Apr 13, 2017

0xdevalias commented Apr 13, 2017

dsander commented Apr 15, 2017

Skarlso commented May 10, 2017

0xdevalias commented May 10, 2017

Skarlso commented May 10, 2017 • edited Loading

0xdevalias commented May 10, 2017

dsander commented May 10, 2017

baip commented May 25, 2018

0xdevalias commented Mar 28, 2024

0xdevalias commented Mar 2, 2017 •

edited

Loading

0xdevalias Mar 5, 2017 •

edited

Loading

0xdevalias Mar 6, 2017 •

edited

Loading

0xdevalias commented Mar 8, 2017 •

edited

Loading

0xdevalias commented Mar 9, 2017 •

edited

Loading

0xdevalias commented Mar 11, 2017 via email •

edited by cantino

Loading

0xdevalias commented Mar 19, 2017 •

edited

Loading

0xdevalias commented Apr 10, 2017 •

edited

Loading

Skarlso commented May 10, 2017 •

edited

Loading