Skip to content
This repository has been archived by the owner on Aug 29, 2022. It is now read-only.

added new version of Dockerfile and convenience script #2

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

meridius
Copy link

I took a liberty of rewriting the Dockerfile to be more lightweight and added a convenience script.

The image now also includes Docker for serverless invoke local --docker -f myFunction to work. This however needs mounted Docker socket and group of user able to access it.
To make the work with the image easier I've created script that does all the heavy lifting and updated README accordingly.

I'm open to suggestions.
Thank you

@meridius
Copy link
Author

Hi @mnapoli, I'm sure you have a lot on your plate already and I'm grateful for the work you do, but could you please consider looking into this PR? It's not a blocker for me since I already use it from my branch, but I think others might find it useful if it was merged.
Especially if they're new to Bref, installing the necessary tools and their dependencies might be too much of a curve for them (as it was for me). Luckily bref/dev-env image exists to make introduction to Bref easier.
Shame is that it's not mentioned anywhere in the https://bref.sh/docs. I'd like to change the documentation as well once this is merged because it slightly changes how one can work with Bref.

Thank you again

meridius added a commit to meridius/bref that referenced this pull request May 10, 2020
@mnapoli mnapoli added the enhancement New feature or request label May 12, 2020
@mnapoli
Copy link
Member

mnapoli commented May 12, 2020

Hi, thank you for the PR!

I did view that at the time and thought "oh that's a complete rewrite, I need to take time to review this properly" and never got that time. Merging a rewrite in a pull request is the hardest thing to be honest. I can't just hit merge and commit to maintain your code just like that.

I need to understand why each line was changed. I'm sure there are good reasons for each of them, but I can't "guess" why you changed it.

Here are ways to get out of this situation:

  • you could comment every change in the PR (yes every single one) so that we can review them one by one
  • you could open one PR per change (easy to merge, but easy to get conflicts)
  • same strategy as about (one PR per change) but base each PR on top of each other, that would minimize conflicts and ease your work (unless some code change in some review)
  • you could revert most changes and focus on the most important ones for now (and explain these changes)

Another problem we need to solve here is the installation of the dev-env script. On master, users don't have to install anything. With your changes, they have to install that script.

Don't get me wrong, that script is awesome. I'm just looking at "how" we can simplify the installation.

One solution for that could be to move it in Bref (e.g. vendor/bin/bref-dev), that way nothing to install and it's available to everyone?

@meridius
Copy link
Author

Hi, thank you for your time and proposals!

I get why you're so reluctant to merge that (I'd be too). So unless I change my mind for some reason, I think I'll go with option 1 (commenting each line) because it seems the most logical for me and actually the least of work. I'll get to that in a couple day's time.

Regarding the script.
We sure can put it to the Bref itself, but that would kind of defeat its purpose since the script is meant to ease the work with the container so user wont' have to install PHP (in any way) and other deps, but Bref itself requires PHP (and Composer) to be installed.
I think there is a third way - to have it elsewhere completely and/or just link it as a downloadable from Bref Doc.
Anyway, as already said, the script is a nice-to-have, user can use the image without it.

Thank you again and have a nice time.

@mnapoli
Copy link
Member

mnapoli commented May 12, 2020

We sure can put it to the Bref itself, but that would kind of defeat its purpose since the script is meant to ease the work with the container so user wont' have to install PHP (in any way) and other deps, but Bref itself requires PHP (and Composer) to be installed.

Oh yeah that's a good point!

I think there is a third way - to have it elsewhere completely and/or just link it as a downloadable from Bref Doc.

Yep, good idea. E.g. curl https://bref.sh/bref-dev.sh or something like that.

I think I'll go with option 1 (commenting each line) because it seems the most logical for me and actually the least of work. I'll get to that in a couple day's time.

👍 awesome thank you

Dockerfile Outdated
ENV PATH="/root/.serverless/bin:/root/.local/bin:${PATH}"

WORKDIR '/var/task'
FROM composer:1.10.4
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the start I chose to use Alpine-based image for the following reasons:

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
FROM composer:1.10.4
# This image is based on Linux Alpine, a lighter image than debian/ubuntu
FROM composer:1.10.4

By the way, why not use the latest version?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the comment really necessary? I mean yes, it's smaller than something else, but we could pick many other facts. Should we state them too? And how would we know which ones?

And for the latest. You really shouldn't use it when you need to do something that depends on the system version. For example we know that Alpine 3.11 has docker=19.03.5-r0 in repository, but what will the latest a month from now have?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the comment really necessary? I mean yes, it's smaller than something else, but we could pick many other facts. Should we state them too? And how would we know which ones?

This comment is to make my life, as maintainer, easier. In 1 year, I will stumble on that code and not remember why we chose that image over a classic linux distribution.

And for the latest. You really shouldn't use it when you need to do something that depends on the system version. For example we know that Alpine 3.11 has docker=19.03.5-r0 in repository, but what will the latest a month from now have?

Good point.

So does that mean that I will have to regularly update the version here, and then update the Docker version below too? How can I find the Docker version for the Alpine version that is referenced here?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought the latest through again and I think we can use it in this situation eventually. The only things we might require specific versions of are only serverless and awscli, and maybe even those not. So if we leave out specifying package versions we can have the base system as latest.
I'll push the changes.

BTW, you can find the available packages per Alpine release at https://pkgs.alpinelinux.org/packages?name=docker&branch=v3.11&arch=x86_64

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Show resolved Hide resolved
Dockerfile Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
dev-env Show resolved Hide resolved
dev-env Show resolved Hide resolved
dev-env Show resolved Hide resolved
fi

docker run --rm --interactive --tty \
--user "$(id -u)":"$(id -g)" \
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

necessary so all files created in container are actually owned by the user running this container

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
--user "$(id -u)":"$(id -g)" \
# So that all files created in container are actually owned by the user running this container
--user "$(id -u)":"$(id -g)" \

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment breaks the multiline command, so I'd put the explanation under Explanations in README.md instead.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll add it above the docker run command instead.

dev-env Show resolved Hide resolved
dev-env Show resolved Hide resolved
dev-env Show resolved Hide resolved
--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \
--volume "${AWS_CONF_DIR}:/home/app/.aws" \
--volume "${PWD}:/app" \
"bref/dev-env" "$@"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and final one - to pass all commands to the container

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"bref/dev-env" "$@"
# "$@" forwards all the arguments to the container
"bref/dev-env" "$@"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The $@ is pretty basic Bash knowledge, but if you really want to have it described it'd have to be put somewhere else (above, below, in README.md) than in the middle of multiline command.

Copy link
Member

@mnapoli mnapoli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That looks great!

I think some of these comments deserve to be persisted so I added suggestions to add them inline in the code.

I think we are moving forward!

Dockerfile Outdated
ENV PATH="/root/.serverless/bin:/root/.local/bin:${PATH}"

WORKDIR '/var/task'
FROM composer:1.10.4
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
FROM composer:1.10.4
# This image is based on Linux Alpine, a lighter image than debian/ubuntu
FROM composer:1.10.4

By the way, why not use the latest version?

Dockerfile Outdated
&& composer global require hirak/prestissimo \
&& apk add --no-cache \
docker=19.03.5-r0 \
yarn=1.19.2-r0 \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All Bref docs mention npm, could we install it? (we can also have yarn, why not)

Dockerfile Show resolved Hide resolved
Dockerfile Outdated
Comment on lines 21 to 25
&& pip3 install \
--progress-bar off \
--no-cache-dir \
--disable-pip-version-check \
awscli==1.18.39
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 thanks

Could you add this information into a comment?

awscli==1.18.39

USER app
ENV PATH=$PATH:/tmp/vendor/bin \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure which packages you have in mind?

Do you have an example of a use case?

COMPOSER_HOME=/app/.composer
VOLUME /app
VOLUME /home/app/.aws
VOLUME /var/run/docker.sock
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
VOLUME /var/run/docker.sock
# Change the docker socket file location for successfully running Docker in Docker.
VOLUME /var/run/docker.sock

fi

docker run --rm --interactive --tty \
--user "$(id -u)":"$(id -g)" \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
--user "$(id -u)":"$(id -g)" \
# So that all files created in container are actually owned by the user running this container
--user "$(id -u)":"$(id -g)" \

dev-env Show resolved Hide resolved
--user "$(id -u)":"$(id -g)" \
--group-add "${DOCKER_GROUP_ID}" \
--env HOST_AWS_CONF_DIR="${AWS_CONF_DIR}" \
--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \
# Necessary for Docker in Docker
--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment breaks the multiline command. In addition the explanation is already mentioned under Explanations in README.md.

--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \
--volume "${AWS_CONF_DIR}:/home/app/.aws" \
--volume "${PWD}:/app" \
"bref/dev-env" "$@"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"bref/dev-env" "$@"
# "$@" forwards all the arguments to the container
"bref/dev-env" "$@"

Dockerfile Outdated
ENV PATH="/root/.serverless/bin:/root/.local/bin:${PATH}"

WORKDIR '/var/task'
FROM composer:1.10.4
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the comment really necessary? I mean yes, it's smaller than something else, but we could pick many other facts. Should we state them too? And how would we know which ones?

And for the latest. You really shouldn't use it when you need to do something that depends on the system version. For example we know that Alpine 3.11 has docker=19.03.5-r0 in repository, but what will the latest a month from now have?

Dockerfile Outdated
&& composer global require hirak/prestissimo \
&& apk add --no-cache \
docker=19.03.5-r0 \
yarn=1.19.2-r0 \
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, the docs mention it exactly 3 times:

But I guess we can have npm too, if you insist. I don't really mind.

Dockerfile Outdated
Comment on lines 21 to 25
&& pip3 install \
--progress-bar off \
--no-cache-dir \
--disable-pip-version-check \
awscli==1.18.39
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
&& pip3 install \
--progress-bar off \
--no-cache-dir \
--disable-pip-version-check \
awscli==1.18.39
&& pip3 install \
--progress-bar off \
--no-cache-dir \
--disable-pip-version-check \
awscli==1.18.39
##
# pip3 install options explained:
# --no-cache-dir makes resulting image is smaller
# --disable-pip-version-check makes build quicker
# --progress-bar off makes output cleaner
# --upgrade is not necessary since we don't want to deal with its upgrade anyway
# --user is not necessary since we're still root
##

However I'm against explaining options since user should be able to read it easily from their names (that's why i don't use short variants, if at all possible) and if not they should read docs of given program where more information and related info could be.

--disable-pip-version-check \
awscli==1.18.39

USER app
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • TODO: try to not create the app user

Dockerfile Outdated Show resolved Hide resolved
Dockerfile Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
fi

docker run --rm --interactive --tty \
--user "$(id -u)":"$(id -g)" \
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment breaks the multiline command, so I'd put the explanation under Explanations in README.md instead.

--user "$(id -u)":"$(id -g)" \
--group-add "${DOCKER_GROUP_ID}" \
--env HOST_AWS_CONF_DIR="${AWS_CONF_DIR}" \
--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment breaks the multiline command. In addition the explanation is already mentioned under Explanations in README.md.

--volume "${DOCKER_SOCK_PATH}:/var/run/docker.sock" \
--volume "${AWS_CONF_DIR}:/home/app/.aws" \
--volume "${PWD}:/app" \
"bref/dev-env" "$@"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The $@ is pretty basic Bash knowledge, but if you really want to have it described it'd have to be put somewhere else (above, below, in README.md) than in the middle of multiline command.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants