bcgov / bcgov/ligo-lib

Docker Misc

Open
#8 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
1
Forks
1
PR merge metrics
No merged PRs in 30d

Description

Review comment: We can go for a higher version if we want right?
https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/django/Dockerfile-dev#L1
(It is my mistake anyway, I copied and used the Python version from the Docker sample files generated by the the cookie cutter Django setup that Khalegh used)

Review comment: it is my mistake - in the final version of docker ticket related work
I am not relying on start-dev.sh;
so any line in the file https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/django/Dockerfile-dev that refers to start-dev.sh can be taken out/removed.

Review comment: the comment here (https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/django/entrypoint.sh#L18) no longer matches the latest state of docker-compose. I guess Khalegh replaced Alpine postgres is replaced with postgres 9.6.

We can mark that we are not using https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/django/start-dev.sh, https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/django/gunicorn.sh and https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/django/Dockerfile

This file is very useful in terms of understanding docker related concepts but we are not using this file either: https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/docs/docker_ec2.rst

This is repeated as part of the comments related to db/algorithms file:

Review comment: At https://github.com/bcgov-c/data-linking/blob/develop-2.0/web/linkage/compose/postgres/Dockerfile#L4

we could use alpine postgres as that one has smaller resource requirement .
Is there any specific reason behind using postgres:9.6?

(I beleive in my commit for containerizing the code I had Alpine postgres)
Also one main question is how is plpythonu extension getting integrated into
postgresql (residing on containers); where are we taking care of it?
The need for plpythonu was not clear from the state of the master branch when I worked on the docker ticket. So we may need to build postgres image instead of using the one
already available on dockerhub.
Also the last u in the name plpythonu says it might be used in malicious ways
(https://www.postgresql.org/docs/9.6/static/plpython.html)

Review comment: I am not confident about the malicious/non-malicious characteristics/intent of the images (used in docker-dev or docker-compose) that I am layering upon or using. Wondering could we use something like https://github.com/coreos/clair or https://blog.docker.com/2016/05/docker-security-scanning/ to scan for vulnerabilities?

Contributor guide

Open the contributing guide

Research direction

Start by reviewing compose/django/Dockerfile-dev, entrypoint.sh, the listed unused scripts and Dockerfile, docs/docker_ec2.rst, and compose/postgres/Dockerfile. Trace the current docker-compose setup and how plpythonu is provided. Done means the obsolete references and documentation are resolved, image choices and extension handling are decided, and any vulnerability-scanning scope is documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, postgresql, python
Domain
databases, devops, security
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.