This motivated me to learn Docker and gcloud rather quickly.

I was able to create a new Docker container in a short time. However, as I don’t want to share my Git SSH key publicly, I needed a way to put an SSH private key (~/.ssh/id_rsa) into this new container securely, without leaving any trace.

I tried a few things, but in the end, I decided to do something like:

FROM python:3.5-stretch as intermediate

# add credentials on build
RUN mkdir /root/.ssh/
# To use docker --build-arg, you can uncomment the following two lines and comment out the COPY line below.
# ARG SSH_PRIVATE_KEY
# RUN echo "${SSH_PRIVATE_KEY}" > /root/.ssh/id_rsa
COPY application_sshkey /root/.ssh/id_rsa
RUN chmod 0600 /root/.ssh/id_rsa

# make sure your domain is accepted
RUN touch /root/.ssh/known_hosts
RUN ssh-keyscan bitbucket.org >> /root/.ssh/known_hosts

RUN git clone git@bitbucket.org:username/application /root/application

FROM python:3.5-stretch
COPY --from=intermediate /root/application /root/application

RUN pip3 install -r /root/application/requirements.txt

EXPOSE 9090/tcp

WORKDIR /root/application/

CMD python3 manage.py runserver 0.0.0.0:9090

Here, application_sshkey is a file I created using ssh-keygen and granted read-only access to on Bitbucket.

As you can see, the Dockerfile has two FROM statements. It creates a container to clone the application repository. Then it starts again with a new container and copies the repository to this new container. This way, it is not possible to peek into the private key using the docker history command.

By the way, I included two methods in the Dockerfile because gcloud builds does not accept a --build-arg parameter similar to docker build. I’m sure there are other workarounds for passing secrets to gcloud builds, but instead of digging for them, I found a solution that works for both Docker and Google Cloud Run.

Instead, we use parameter passing to the database engine. For example:

SELECT * FROM people WHERE name = ?

We send this query and the parameters separately to the database. Most modern database systems support this approach.

In SQLite 3 with Python, we use it like this:

query = "SELECT * FROM people WHERE name = ?"
params = (name,)
db_result = cursor.execute(query, params)

However, when debugging, we may need to see the actual queries sent to the database—for instance, when data types are important or when we suspect a column is receiving a string instead of an integer.

In these cases, rather than manually reconstructing the query, we can use the set_trace_callback feature available in Python 3.3 and later:

connection.set_trace_callback(print)

The argument can be any function (such as print or a logger function) or None to disable tracing. This makes it easy to integrate with Python’s standard logging module.