Enable dev env on AAP-15607 #562
Conversation
msmagnanijr
changed the title
msmagnanijr
force-pushed
the
AAP-15607-compose
branch
2 times, most recently
from
69011ac
to
45d85af
Compare
|
Two questions:
|
I spoke to @mkanoor about this, and the idea was not to mix up the settings. There was something else about MacOS that I can't remember now.
I've compiled a document with a step-by-step guide on generating valid certificates using Red Hat's internal CA, but unfortunately, it still didn't work. If, in the end, we have to resort to using self-signed certificates, I agree to have everything prepared in the repo. @mkanoor what do you think? |
|
I think @mkanoor meant to do this in a separated PR and because the changes for mac will be different than for linux. But I don't see a reason to have a new docker-compose. Regarding the certs. I think it is not worth to add complexity and/or manual steps to deploy the environment. The goal is to work in a setup with SSL to be closer to production, not to provide a real secure environment. A self-signed cert for the development/stage environment inside the repo is a common approach and completely acceptable to me. |
msmagnanijr
force-pushed
the
AAP-15607-compose
branch
from
4e824a0
to
e210cd5
Compare
|
@Alex-Izquierdo We are trying to get certs from our internal CA and try this end to end with SSL for While we have certs we have to make sure that we test everything works with it, but there is a manual step to get the certs from our CA which takes about 1 day. Since not all developers would be using this from the get go it would take a while for everyone to get the certs. The docker-compose-dev-ssl.yml is the file which we would eventually keep once everyone has migrated over. Since we have to mount the certs locally from every developers machine to the containers, if we have a single docker compose we would have to make the mount conditional or keep a separate file. Keeping it separate with an ssl suffix will help in development without breaking everyone else's env. |
|
Ok, that makes sense. |
msmagnanijr
force-pushed
the
AAP-15607-compose
branch
2 times, most recently
from
40062ea
to
1afb1d1
Compare
|
@ansible/eda-maintainers whenever you get a chance, could you please review this? tks |
|
@msmagnanijr can you resolve the conflict pls? |
Yep, I am working on it. |
See: https://issues.redhat.com/browse/AAP-15607 Signed-off-by: Mauricio Magnani <[email protected]>
msmagnanijr
force-pushed
the
AAP-15607-compose
branch
from
1afb1d1
to
7e58570
Compare
Signed-off-by: Mauricio Magnani <[email protected]>
| @@ -199,4 +199,4 @@ volumes: | |||
|
|
|||
| networks: | |||
| service-mesh: | |||
| name: service-mesh | |||
| name: service-mesh | |||
There was a problem hiding this comment.
I think you don't have rebased it properly, this change is already on main. https://github.com/ansible/eda-server/blob/main/tools/docker/docker-compose-dev.yaml#L202
There was a problem hiding this comment.
have you look at this?
|
@msmagnanijr I don't have enough expertise to review this. How to use this work? Is it to do docker compose based on tools/docker/docker-compose-tls.yaml then it will automatically enable the ssl connection to DB with all key and cert provided out of box? Otherwise can you document the procedure? |
Yes, Mahdu asked me to create this. Let me just give one last review and I'll share the doc. @bzwei I added the doc link here https://issues.redhat.com/browse/AAP-15607 tks |
Signed-off-by: Mauricio Magnani <[email protected]>
There was a problem hiding this comment.
Do we need a new docker-compose file? Would make sense to merge it with the existing https://github.com/ansible/eda-server/blob/main/tools/docker/docker-compose-dev-redis-tls.yaml ?
I think it makes sense now. I think we had thought about creating another one for some reason so as not to impact the compose-dev |
|
Closing since I'm dealing with this here: #907 |
See: https://issues.redhat.com/browse/AAP-15607