THREESCALE 12122: Fix tests suite with SSL #576
Conversation
jlledom
force-pushed
the
THREESCALE-12122-test-ssl
branch
from
644af9b to
43544ee
Compare
jlledom
force-pushed
the
THREESCALE-12122-test-ssl
branch
from
3e96487 to
2b3ef8e
Compare
| [allowlist] | ||
| description = "Global Allowlist" | ||
|
|
||
| # Ignore based on any subset of the file path | ||
| paths = [ | ||
| # Ignore all fake private keys for CircleCI, they are for tests | ||
| '''.circleci\/.+\.(pem|key)$''' | ||
| ] |
There was a problem hiding this comment.
This is to bypass our secret leak detector. The certificates I pushed here are fake.
| @@ -1,4 +1,77 @@ | |||
| version: 2.1 | |||
|
|
|||
| commands: | |||
There was a problem hiding this comment.
Both jobs run the same tests, this is to reuse them
| commands: | ||
| bundle_install: | ||
| parameters: | ||
| run_in_zync: |
There was a problem hiding this comment.
When true, we run the command inside zync container, required for SSL
| postgresql_image: | ||
| type: string | ||
| machine: | ||
| image: ubuntu-2204:current |
There was a problem hiding this comment.
The docker executor doesn't accept mounting volumes to the postgres container, I faced the same issue when I added SSL pipelines to apisonator. We must use the mahine executor and launch the containers manually.
There was a problem hiding this comment.
I read that setup_remote_docker step allows for using docker from within the main container, so that we can use the old approach, just add the setup remote docker step to then run postgres as we wish.
But also it is in fact not hard to start postgres with a custom entrypoint that generates a SSL certificate.
podman run --rm -e POSTGRES_HOST_AUTH_METHOD=trust -e POSTGRES_DB=test --entrypoint bash cimg/postgres:15.15 -c ' openssl req -nodes -new -x509 -subj "/CN=localhost" -keyout /server.key -out /server.crt && chown postgres /server.* && exec docker-entrypoint.sh postgres -c ssl=on -c ssl_cert_file=/server.crt -c ssl_key_file=/server.key '
Then we can extract the CA in the main container with:
openssl s_client \
-starttls postgres \
-connect localhost:5432 \
-showcerts < /dev/null > ca.pem
I think both options are preferable to switching to the VM executor especially if we anticipate using custom executors. WDYT about these options?
There was a problem hiding this comment.
That might work, I don't know, but I don't think it's worth the effort because every change you make in the CircleCI file, even if it seems easy, always ends up taking a whole day of try & error. I don't see much improvement on using a docker executor over a machine executor to justify the effort.
There was a problem hiding this comment.
even if it seems easy, always ends up taking a whole day of try & error
That's true. But also this native executor is very shitty with some old software like old podman and stuff. And then it makes it much harder to use custom executors. Also current approach looks complicated, although I can't tell if using pure docker executor will make it noticeably less complicated 🤔
There was a problem hiding this comment.
It's gonna be complicated whatever approach we try. CircleCI won't allow you to pass until you hit your head against a wall for at least 8 hours.
| cp /tmp/server.crt /server.crt | ||
| cp /tmp/server.key /server.key | ||
| cp /tmp/ca.crt /ca.crt | ||
| chown postgres:postgres /server.crt /server.key /ca.crt | ||
| chmod 600 /server.key | ||
| exec docker-entrypoint.sh postgres -c ssl=on -c ssl_cert_file=/server.crt -c ssl_key_file=/server.key -c ssl_ca_file=/ca.crt |
There was a problem hiding this comment.
All this is because postgres doesn't accept a cert key which is not owned by itself and with 0600 permissions
| - store_test_results: | ||
| path: test/reports | ||
|
|
||
| chmod 600 $(pwd)/.circleci/circleci.key && \ |
There was a problem hiding this comment.
postgres doesn't accept the client not owning the client key neither, and permissions must be 0600 as well
| run_in_zync: true | ||
| - boot_zync: | ||
| run_in_zync: true | ||
| - save_cache: |
There was a problem hiding this comment.
save cache should be directly under bundle install maybe 🤔
| <<# parameters.run_in_zync >> | ||
| circleci tests glob "test/**/*_test.rb" | circleci tests run --command="xargs docker exec zync bundle exec rake test TESTOPTS='-v'" --verbose --split-by=timings | ||
| <</ parameters.run_in_zync >> | ||
| <<^ parameters.run_in_zync >> |
There was a problem hiding this comment.
can you explain a little the parameters syntax and choices?
There was a problem hiding this comment.
Yes:
<<# parameters.run_in_zync >>: This means "if parameters.run_in_zync is true"
<<^ parameters.run_in_zync >>: This means "if parameters.run_in_zync is false"
<</ parameters.run_in_zync >>: This is just to close the if statement
So when run_in_zync is true, it runs the tests inside the zync container (it adds docker exec zync ...). Otherwise it doesn't.
2 participants
This is kinda part of https://issues.redhat.com/browse/THREESCALE-12122
Que was not supporting SSL protected DBs at all, and then I opened #573 to fix it. I tested and everything works fine now, and Que can work with a SSL DB properly. However, I found out during the Rails 8 upgrade that the test suite is also broken when using a SSL DB, so this PR is to fix that.
You can find more context in this discussion: #560 (comment)
Now we have a PR only for this, I think it the time to edit the pipeline and add a job to test SSL DBs as well.