Docker Install instructions are out of date

[amandasaurus]

URL

No response

How to reproduce the issue?

The current Docker install instructions talk about installing Docker Compose, but I think Docker should be done with Docker Desktop which includes docker compose. (according to their website).

The instructions use docker-compose command, but I think it's docker compose now.

(I know very little about docker, this is just something I experienced when trying to set the project up)

Screenshot(s) or anything else?

No response

[gravitystorm]

Thanks! These parts of the install instructions (i.e. the manual bits that aren't covered by our automated testing) are always the hardest to keep on top of.

[tomhughes]

WTF is docker desktop when it's at home? We don't want to do anything that only works in some sort of GUI environment...

[amandasaurus]

On Sun, 26 Feb 2023 0:57 +01:00, Tom Hughes ***@***.***> wrote: WTF is docker desktop when it's at home? We don't want to do anything that only works in some sort of GUI environment...

lol, I've no idea. It wants to start some GUI app where you have to agree to some sort of contract or bullshit agreement. 🤷🏻‍♀️🤣

…

-- Amanda

[icemagno]

Another Docker install problem:

 => [ 6/10] ADD Gemfile Gemfile.lock /app/                                                                            0.1s
 => [ 7/10] RUN gem install bundler  && bundle install                                                              295.1s
 => [ 8/10] ADD package.json yarn.lock /app/                                                                          0.0s
 => [ 9/10] ADD bin/yarn /app/bin/                                                                                    0.0s
 => ERROR [10/10] RUN bundle exec bin/yarn install                                                                    0.8s
------
 > [10/10] RUN bundle exec bin/yarn install:
#0 0.744 bundler: not executable: bin/yarn
------
Dockerfile:50
--------------------
  48 |     ADD package.json yarn.lock /app/
  49 |     ADD bin/yarn /app/bin/
  50 | >>> RUN bundle exec bin/yarn install
  51 |
--------------------
ERROR: failed to solve: process "/bin/sh -c bundle exec bin/yarn install" did not complete successfully: exit code: 126

[tomhughes]

Yes docker is shit. For the sake of all that's holy please don't use it. It makes no sense for a development enviroment.

[icemagno]

@tomhughes I don't think Docker is shit. I'm a microservice architect and Docker is the best way to deploy and keep things and even distribute your products. But some teams that have legacy products and are trying to port it to Docker may have huge problems if they don't take this seriously.

I think maven / npm was a next level to deliver our softwares. When I give you my "src" and a POM, will be easy to you to rebuild it.

Docker is one step ahead when allow me to give you my software already running with all guarantees that it will run.

What we are facing here is that they are asking WE to build a Docker image instead offer it from the Docker Hub already cooked.

This is not the way.

But I get your point. I think you mean "in this case..."

Anyway... It will be great if I have a Docker image just to taste the product before spend hours to install ..

By the way... now I have your attention... you're doing a very good job. Congrats !

[icemagno]

This is the correct Dockerfile that worked to me:

FROM ubuntu:20.04

ENV DEBIAN_FRONTEND=noninteractive

# Install system packages then clean up to minimize image size
RUN apt-get update \
 && apt-get install --no-install-recommends -y \
      build-essential \
      curl \
      default-jre-headless \
      file \
      firefox-geckodriver \
      libarchive-dev \
      libffi-dev \
      libgd-dev \
      libpq-dev \
      libsasl2-dev \
      libvips-dev \
      libxml2-dev \
      libxslt1-dev \
      locales \
      nodejs \
      postgresql-client \
      ruby2.7 \
      ruby2.7-dev \
      tzdata \
      unzip \
	  gnupg 

RUN curl -sS https://dl.yarnpkg.com/debian/pubkey.gpg | apt-key add -
 
RUN echo "deb https://dl.yarnpkg.com/debian/ stable main" | tee /etc/apt/sources.list.d/yarn.list
RUN apt-get update && apt-get install -y yarn
RUN apt-get -y upgrade

RUN apt-get clean \
 && rm -rf /var/lib/apt/lists/*

ENV DEBIAN_FRONTEND=dialog

# Setup app location
RUN mkdir -p /app
WORKDIR /app

COPY ./ /app/

# Install Ruby packages
ADD Gemfile Gemfile.lock /app/
RUN gem install bundler \
 && bundle install

# Install NodeJS packages using yarn
ADD package.json yarn.lock /app/
ADD bin/yarn /app/bin/
RUN yarn config set ignore-engines true
RUN bundle exec yarn install
RUN touch config/settings.local.yml

[tomhughes]

Containerisation is fine for production services, but it doesn't fit with what it is being used for here as a development tool because there is a tension between building an image and wanting to edit the code as you develop it.

As it stands for example if you want to change or update the gems you can't just edit the Gemfile and update the bundle, you have to rebuild the image and restart it.

Yet for some reason that's not true for the node modules which are stored on a mounted volume but there's no logical reason for that difference other presumably than whoever wrote it found it more inconvenient to have to rebuild the image if they changed the node modules.

All of which means nobody doing serious development is going to use it so they never notice when it breaks and the CI that tries to test it is not reliable and constantly fails for mysterious reasons.

So it is no use to us personally as maintainers yet imposes costs on us dealing with tickets like this.

[gravitystorm]

So it is no use to us personally as maintainers yet imposes costs on us dealing with tickets like this.

Yeah, it certainly imposes costs on the maintainers (I don't use it either). But I can totally understand why people are interested in having isolated development environments, and there's many people who want to "dip their toes" by making some small changes and don't want to have to install everything required (from postgres to libvips to node to ruby etc). I can see that at e.g. a recent hack weekend. People want to work on this for a few hours and then dispose of the development environment without affecting their personal laptop setup.

We also have a vagrant setup, which is an alternative (and slightly more resource intensive, and equally as unused) approach to having an isolated development environment.

So what I would like to see is some guidance on how best to use Docker for isolated development environments, balancing the advantages of isolation with a certain amount of using the underlying filesystem (for ease of editing). If anyone has any third-party resources on this that could be helpful.

In the meantime, this has drifted slightly away from the OP comment, which is that Docker have rebranded their software, particularly for Windows and Mac, and now bundle the two components that we currently describe individually. We should refocus this issue on updating our guidance as to what needs to be installed for the different platforms, so that our installation notes match what a developer will see when they follow the links.

[icemagno]

Ok. I am thinking as final user. My focus is not to develop or change this product in any way.

This is because I think like a "fire and go" environment.

By leaving all permanent stuff inside the image I can guarantee all will work at same way forever with a minimum intervention.

I've exposed only the yaml files so all the next people need to do is change they and run.

I agree with both of you each with your purpose and final goal.

My goal is not concerning about how to run or customize but run it as fast as I can to take care of my own busenes.

And if I change my infrastructure or lost my server in the future I know I will not lost my time doing all of this again.

Just docker pull and docker run ...

"If it work once... will work forever..."

[GobinathAL]

As it stands for example if you want to change or update the gems you can't just edit the Gemfile and update the bundle, you have to rebuild the image and restart it.

I disagree. You can write "volume" for your docker container which will mount the code to the container. The file in the container changes when the file in your local changes. Provided you're not using a ruby-slim image and the gem that you need to add doesn't need any additional OS libraries, you can just add a gem and bundle install

[tomhughes]

Yes you could do that but that isn't what it does - the vendored javascript is mounted from the host but the gems are installed as part of the container image.