Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feat/37 client docker file #115

Merged
merged 5 commits into from
Jan 30, 2024
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions .github/workflows/build-and-test.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,45 @@
name: Build and Test Reporting App

on:
push:
branches: [develop, main]
pull_request:
branches: [develop, main]
workflow_dispatch:

jobs:
frontend-docker-build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Docker Buildx
id: buildx
uses: docker/setup-buildx-action@v3
with:
install: true
- name: Docker meta
id: meta
uses: docker/metadata-action@v5
with:
images: ghcr.io/bcgov/cas-reporting-frontend
tags: |
type=sha,format=long,prefix=
latest
type=ref,event=pr
- name: Login to GitHub Container Registry
uses: docker/login-action@v3
with:
registry: ghcr.io
username: ${{ github.repository_owner }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build image
uses: docker/build-push-action@v5
with:
context: client
builder: ${{ steps.buildx.outputs.name }}
push: true
file: client/Dockerfile
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
cache-from: type=gha
cache-to: type=gha
48 changes: 48 additions & 0 deletions client/Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
FROM debian:11

RUN apt-get update && \
apt-get install -y git gnupg curl && \
apt-get clean

ENV USER_ID=1001
ENV HOME=/root

WORKDIR ${HOME}

COPY ./ ${HOME}/

RUN git clone https://github.com/asdf-vm/asdf.git ${HOME}/asdf --depth 1 --branch v0.14.0

ENV BASH_ENV="${HOME}/asdf/asdf.sh"
# Because asdf is loaded via BASH_ENV, all commands using adsf need to be executed using /usr/bin/env bash -c
SHELL ["/usr/bin/env", "bash", "-c"]

COPY .tool-versions ${HOME}/.tool-versions
# The client only needs yarn and node
RUN sed -i -nr '/node|yarn/p' ${HOME}/.tool-versions && \
cat ${HOME}/.tool-versions | cut -f 1 -d ' ' | xargs -n 1 asdf plugin-add && \
asdf plugin-update --all && \
asdf install && \
asdf reshim

ADD https://github.com/Yelp/dumb-init/releases/download/v1.2.5/dumb-init_1.2.5_x86_64 /usr/local/bin/dumb-init
RUN chmod +x /usr/local/bin/dumb-init
ENTRYPOINT ["dumb-init", "--"]

ENV NODE_ENV=production

RUN yarn install --frozen-lockfile --production=false && \
yarn build && \
yarn install --frozen-lockfile --production=true && \

Choose a reason for hiding this comment

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

What is the reasoning behind running yarn install with production set to false, and then to true?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was kind of wondering the same, it's setup the same way in the registration app.
I'm assuming it's to ensure the development build works as well? Maybe @dleard or @andrea-williams has context to give us

Choose a reason for hiding this comment

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

Unless their docs are off, the only difference is that with production=false our dev dependencies will be installed. In that case the second install won't do anything. If we need something from our dev dependencies for the build to happen well, we could consider removing the node_modules after the yarn build and then running the install in production mode.

Definitely not a huge deal, I was just curious.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd say - let's remove the whole dev statement. There is no need to ship a production image with dev dependencies, this might increase the attack surface if those deps have vulnerabilities?

Choose a reason for hiding this comment

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

I agree, and if nothing else we'll shrink our image a little bit, which feels like a win win to me!

Choose a reason for hiding this comment

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

I'm afraid I have no insight into why the Dockerfile is written that way. It's a question for either Dylan or @Sepehr-Sobhani

Copy link
Contributor

Choose a reason for hiding this comment

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

This seems to be a leftover from copying and pasting the Dockerfile from CIF.

yarn cache clean && \
# Make everything in the home group-writable to support OpenShift's restricted SCC
# Needs to be done as root to chown
# same layer as yarn install to keep re-chowned files from using up several hundred MBs more space
useradd -ms /bin/bash -d ${HOME} --uid ${USER_ID} -g root client && \
chown -R client:0 ${HOME} && \
chmod -R g+rwX ${HOME}

EXPOSE 3000 9000
USER ${USER_ID}

CMD ["/usr/bin/env", "bash", "-c", "yarn start"]