PR#16: Create a production ready Dockerfile - taskotron/resultsdb_frontend

taskotron / resultsdb_frontend

#16 Create a production ready Dockerfile

Closed 4 years ago by rlim. Opened 4 years ago by rlim.

Unknown source dockerize_resultsdb_frontend into master

Create a production ready Dockerfile

rlim • 4 years ago

4398f21

Dockerfile

file modified

+57 -9

		`@@ -1,11 +1,59 @@`
		`- FROM fedoraqa/flask-base:24`
		`+ # This will produce an image to be used in Openshift`
		`+ # Build should be triggered from repo root like:`
		`+ # docker build -f openshift/Dockerfile \`
mprahl commented 4 years ago This doesn't look the right path
		`+ # --tag <IMAGE_TAG>`
		`+`
		`+ FROM registry.fedoraproject.org/fedora:32`
		`+ LABEL \`
		`+ name="ResultsDB_frontend application" \`
		`+ vendor="ResultsDB_frontend developers" \`
		`+ license="GPLv2+" \`
		`+ description="ResultsDB_frontend is a simple application that allows browsing the data stored inside ResultsDB." \`
		`+ usage="" \`
		`+ build-date=""`
		`+`
		`+ USER root`
		`+ COPY ./resultsdb_frontend.spec /opt/app-root/src/resultsdb_frontend/resultsdb_frontend.spec`
		`+`
		`+ # install dependencies defined in RPM spec file`
		`+ RUN dnf -y install findutils rpm-build python3-pip python3-mod_wsgi httpd python3-psycopg2 python3-stomppy \`
mprahl commented 4 years ago `python3-psycopg2` and `python3-stomppy` should not be necessary for the frontend. This looks like it was copied from the ResultsDB Dockerfile.
		`+ && rpm --query --requires --specfile /opt/app-root/src/resultsdb_frontend/resultsdb_frontend.spec \| xargs -d '\n' dnf -y install`
		`+`
		`+ COPY . /opt/app-root/src/resultsdb_frontend/`
		`+ # install using --no-deps option to ensure nothing comes from PyPi`
		`+ RUN pip3 install --no-deps /opt/app-root/src/resultsdb_frontend`
		`+`
		`+ # fix apache config for container use`
		`+ RUN sed -i 's#^WSGISocketPrefix .*#WSGISocketPrefix /tmp/wsgi#' /opt/app-root/src/resultsdb_frontend/conf/resultsdb_frontend.conf`
		`+`
		`+ # config files`
		`+ RUN install -d /usr/share/resultsdb_frontend/conf \`
		`+ && install -p -m 0644 /opt/app-root/src/resultsdb_frontend/conf/resultsdb_frontend.conf /usr/share/resultsdb_frontend/conf/ \`
		`+ && install -p -m 0644 /opt/app-root/src/resultsdb_frontend/conf/resultsdb_frontend.wsgi /usr/share/resultsdb_frontend/ \`
		`+ && install -d /etc/resultsdb_frontend \`
		`+ && install -p -m 0644 /opt/app-root/src/resultsdb_frontend/conf/resultsdb_frontend.conf /etc/httpd/conf.d/`

		`- RUN dnf install -y python-resultsdb_api && dnf clean all`
		`- COPY . /usr/src/resultsdb_frontend`
		`- COPY ./docker_data/settings.py /usr/src/resultsdb_frontend/conf/`
		`- WORKDIR /usr/src/resultsdb_frontend`
		`+ # Change app.secrey_key for production`
		`+ RUN sudo touch /etc/resultsdb_frontend/settings.py`
		+ RUN sudo echo "SECRET_KEY = '`cat /dev/urandom \| tr -dc 'a-zA-Z0-9' \| fold -w 64 \| head -n 1`'" >> /etc/resultsdb_frontend/settings.py
mprahl commented 4 years ago This is not appropriate to store in the container image itself since this is a runtime and sensitive configuration (not really for the frontend) and not a build-time generic configuration. The reason is that for one, anyone that has access to pull the container image could see the secret key and also every deployment using that container image would end up with the same secret key, thus making the secret key nearly useless. Either the `SECRET_KEY` should be set via an environment variable (may require modifying the app) or a `settings.py` should be mounted in the running container using a volume. Anyways, this is outside of the container image building scope but should be documented.
		`+`
		`+ # point RDB_URL to resultsDB`
		`+ RUN echo "RDB_URL = 'http://resultsdb:5001/api/v2.0'" >> /etc/resultsdb_frontend/settings.py`
mprahl commented 4 years ago This is a runtime configuration and a generic build-time configuration. As my previous comment states, either it should be set via en environment variable or a `settings.py` file should be mounted in the running container using a volume. The approach you take should be documented.
		`+`
		`+ # clean up`
		`+ RUN rm -rf /opt/app-root/src/resultsdb_frontend \`
		`+ && dnf -y autoremove findutils rpm-build \`
		`+ && dnf clean all`
mprahl commented 4 years ago Unless the container image's layers are squashed after the image is built, this actually won't reduce the image size. You'd need to do this as part of the `RUN` command that installs the packages.
		`+`
		`+ # EXPOSE 5002/tcp`
mprahl commented 4 years ago This comment should be removed
		`EXPOSE 5002`
		`- ENV DEV true`
		`- RUN pip install -r requirements.txt`
		`-`
		`- CMD ["python", "runapp.py"]`
		`+ CMD ["mod_wsgi-express-3", "start-server", "/usr/share/resultsdb_frontend/resultsdb_frontend.wsgi", \`
		`+ "--user", "apache", "--group", "apache", \`
		`+ "--port", "5002", "--threads", "5", \`
		`+ "--include-file", "/etc/httpd/conf.d/resultsdb_frontend.conf", \`
		`+ "--log-level", "info", \`
		`+ "--log-to-terminal", \`
		`+ "--access-log", \`
		`+ "--startup-log" \`
		`+ ]`
		`+ USER 1001:0`

conf/resultsdb_frontend.conf

file modified

+1 -1

		`@@ -1,4 +1,4 @@`
		`- WSGIDaemonProcess resultsdb_frontend user=apache group=apache threads=5`
		`+ WSGIDaemonProcess resultsdb_frontend user=apache group=apache threads=5 home=/usr/share/resultsdb_frontend`
		`WSGIScriptAlias /resultsdb_frontend /usr/share/resultsdb_frontend/conf/resultsdb_frontend.wsgi`
		`WSGISocketPrefix run/wsgi`

rlim commented 4 years ago

JIRA: https://projects.engineering.redhat.com/browse/CWFHEALTH-530

Contribute a production ready Dockerfile for ResultsDB frontend.

mprahl commented on line 5 of Dockerfile 4 years ago

This doesn't look the right path

mprahl commented on line 21 of Dockerfile 4 years ago

python3-psycopg2 and python3-stomppy should not be necessary for the frontend. This looks like it was copied from the ResultsDB Dockerfile.

mprahl commented on line 52 of Dockerfile 4 years ago

Unless the container image's layers are squashed after the image is built, this actually won't reduce the image size. You'd need to do this as part of the RUN command that installs the packages.

mprahl commented on line 44 of Dockerfile 4 years ago

This is not appropriate to store in the container image itself since this is a runtime and sensitive configuration (not really for the frontend) and not a build-time generic configuration. The reason is that for one, anyone that has access to pull the container image could see the secret key and also every deployment using that container image would end up with the same secret key, thus making the secret key nearly useless.

Either the SECRET_KEY should be set via an environment variable (may require modifying the app) or a settings.py should be mounted in the running container using a volume. Anyways, this is outside of the container image building scope but should be documented.

mprahl commented on line 47 of Dockerfile 4 years ago

This is a runtime configuration and a generic build-time configuration. As my previous comment states, either it should be set via en environment variable or a settings.py file should be mounted in the running container using a volume. The approach you take should be documented.

mprahl commented on line 54 of Dockerfile 4 years ago

This comment should be removed

frantisekz commented 4 years ago

Either the SECRET_KEY should be set via an environment variable (may require modifying the app) or a settings.py should be mounted in the running container using a volume. Anyways, this is outside of the container image building scope but should be documented.

I can make changes to the resultsdb_frontend if you'd want to use the env path. We're doing it this way in oraculum, the base of rdb frontend and oraculum is very similar. ( https://pagure.io/fedora-qa/oraculum/blob/master/f/oraculum/config.py#_172 )

I personally don't have preference for env or settings file mount.

rlim commented 4 years ago

@frantisekz great, could you make the changes to the resultsdb_frontend so the Dockerfile can use the env path; I can update the Dockerfile afterwards to use the env variable

frantisekz commented 4 years ago

@rlim PR pending review: https://pagure.io/taskotron/resultsdb_frontend/pull-request/17 as mentioned privately, posting it here just for reference.

frantisekz commented 4 years ago

@rlim https://pagure.io/taskotron/resultsdb_frontend/pull-request/17 merged, you can find description of the config options in the first comment there :)

Pull-Request has been closed by rlim

4 years ago