-
Notifications
You must be signed in to change notification settings - Fork 244
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Blog: Connecting to a service without SBO #5915
Blog: Connecting to a service without SBO #5915
Conversation
✅ Deploy Preview for odo-docusaurus-preview ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
The blog's not showing a single instance of |
It is not supposed to use SBO to connect, hence there is no
|
- name: username | ||
value: userAdmin | ||
- name: password | ||
value: userAdmin123456 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will make a secret written into the Devfile, most probably pushed to some git repository.
I'm not sure we want to document this method, as it is not encouraged at all
We could use some kind of envFrom
to point to the secret, but Devfile does not support it for now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does devfile support dynamically obtaining values? I mean if we can put kubectl get secrets minimal-secret -ojsonpath='{.data.username}' | base64 -d
inside the devfile, we can avoid having to hard code password.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could add a note acknowledging that it's a bad practice, but this is for example purpose only, or I could find a way to fetch password from the code itself to avoid this practice altogether.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you could start with this solution, by indicating from the very beginning this is not a secure solution, and then continue with more secure solutions (and probaly more difficult ones). That would show the interest of using SBO.
- The simplest solution would be to have an
envFrom
field in the Devfile's container, but this field does not exist. Is it worth asking Devfile team to add it? I'm not sure - You could pass the secret name and the secret keys as environment variables, and the program would be responsible for getting the values from the secret. That means the program needs access to the Kubernetes API, which opens security breaches
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The simplest solution would be to have an envFrom field in the Devfile's container, but this field does not exist. Is it worth asking Devfile team to add it? I'm not sure
When you say envFrom
, do you mean devfile can evaluate the value from the environment variable exposed in your local system?
env:
- name: password
value:
envFrom: $MONGODB_PASSWORD
Something like this? Or more like this https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/inject/pod-secret-envFrom.yaml?
You could pass the secret name and the secret keys as environment variables, and the program would be responsible for getting the values from the secret. That means the program needs access to the Kubernetes API, which opens security breaches
I think asking the program to be responsible for fetching everything would defeat the purpose of this blog. I think I'll go with a note for now, and it's like you said, it might encourage users to try SBO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something like this? Or more like this https://raw.githubusercontent.com/kubernetes/website/main/content/en/examples/pods/inject/pod-secret-envFrom.yaml?
Yes, like this one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will make a secret written into the Devfile, most probably pushed to some git repository.
Would it be possible to leverage the variable substitution feature here? I think this would solve the issue while showing this other feature of odo
.
Not tested, but calling odo dev
with something like this:
# Given that the variables have already been exported
odo dev --var MY_MONGODB_USERNAME --var MY_MONGODB_PASSWORD
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But then devfile would have to interact with the k8s API and that does not make a lot of sense to me from the design standpoint. I don't think devfile is dependent on the K8s API right now, and I'm not sure if they'd be willing to create a dependency now. Can we take this up in cabal?
Yeah, I read that issue right after commenting. It seems like we only want to show that odo can create a Deployment, and a Pod of that Deployment can talk to a Service using env vars. Anyway, it seems like that's what @kadel wants to showcase. However, the flow here is not the same as: $ odo init
$ odo dev
# Now create a service (using helm or operators)
# Next modify the existing devfile to hardcodde service info, and let odo dev do the magic |
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
@valaparthvi please make sure that your blog complies with this. At the moment, |
Signed-off-by: Parthvi Vala <[email protected]>
7b087ac
to
78b7a37
Compare
@valaparthvi thanks for the fixes. /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dharmit The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@valaparthvi Great blog post 👍🏿
I added a few comments below.
Another small comment. The SBO acronym is mentioned all over the place, but I saw nowhere where it was defined. It is clear to us, but might not for readers.
Maybe it could be worth changing the title to something more explicit, like "Binding to a database service without the Service Binding Operator (SBO)".
My 2 cents...
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
- name: username | ||
value: userAdmin | ||
- name: password | ||
value: userAdmin123456 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will make a secret written into the Devfile, most probably pushed to some git repository.
Would it be possible to leverage the variable substitution feature here? I think this would solve the issue while showing this other feature of odo
.
Not tested, but calling odo dev
with something like this:
# Given that the variables have already been exported
odo dev --var MY_MONGODB_USERNAME --var MY_MONGODB_PASSWORD
What do you think?
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
|
||
|
||
## Export environment variables | ||
2. Export the necessary environment variables: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find that exporting these variables at this point is premature. We cannot understand what they are for. I think it would be better to introduce the helm chart before to export them
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, but then if we want to maintain the order of odo init
> odo dev
> deploy charts > wait for odo dev to detect changes, it becomes necessary to export these variables at this point
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The order
- odo init
- odo dev
- deploy chart
is just an example provided by Tomas, I'm not sure it must be respected at all price.
By first deploying the chart (including exportint variables), then running odo init and odo dev, the flow seems more understandable to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is just an example provided by Tomas, I'm not sure it must be respected at all price.
By first deploying the chart (including exportint variables), then running odo init and odo dev, the flow seems more understandable to me
I like the current approach of enabling Helm repo first. But I don't agree with the idea of spinning up Helm chart using it before doing odo init
. If it were me, I would first show that your Go application is deployed using odo dev
, but curl
request made to it is throwing 404 or some error. Thereafter, we spin up the MongoDB database required by the application.
Or maybe, do an odo dev
without all the variables which would help one connect to the MongoDB database. Make a curl
call that returns 404 or some error. Now add information about connection to MongoDB and see how the application returns expected output.
I'm saying this because that's how I think an application developer's flow would be like. But then I have not a lot of application development myself, so correct me if I'm mistaken.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or maybe, do an
odo dev
without all the variables which would help one connect to the MongoDB database. Make acurl
call that returns 404 or some error. Now add information about connection to MongoDB and see how the application returns expected output.I'm saying this because that's how I think an application developer's flow would be like. But then I have not a lot of application development myself, so correct me if I'm mistaken.
I agree with you, but I can't find a flow that works for everyone. For now, I have added a note stating that odo dev
will fail if run before adding connection information(bf76584).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works for me. I discussed this with @feloy and agree with the flow we have now.
## Deploy the application | ||
4. Run `odo dev` to deploy the application on the cluster. | ||
```sh | ||
odo dev --var PASSWORD=$MY_MONGODB_ROOT_PASSWORD --var USERNAME=$MY_MONGODB_ROOT_USERNAME |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, I think it is premature to pass these variables, as they are not existing in the Devfile yet and we are not using them. I think it would be better to wait for steps 7.x before to do this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then I can simply not do odo dev
first and put it after deploying the microservice.
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
I think it might be stirring a little away from the topic at hand. I would rather do that in a separate blog if necessary. |
Signed-off-by: Parthvi Vala <[email protected]>
111e55f
to
bf76584
Compare
@valaparthvi: The following test failed, say
Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here. |
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
- DELETE `/api/places/<id>` - Delete place with id `<id>` | ||
|
||
## Conclusion | ||
To conclude this blog, it is possible to connect your application with another microservice without the Service Binding Operator if you have the correct connection information. Using the Service Binding Operator with a [Bindable Operator](https://github.com/redhat-developer/service-binding-operator#known-bindable-operators) makes it easy for you to not care about finding the connection information and ease the binding. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could add to the conclusion that it is up to the reader to manage the secrets stored in the environment variables MY_MONGODB_ROOT_PASSWORD and MY_MONGODB_ROOT_USERNAME, so they are accessible every time the following command is executed:
odo dev --var PASSWORD=$MY_MONGODB_ROOT_PASSWORD --var USERNAME=$MY_MONGODB_ROOT_USERNAME --var HOST="mongodb"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added this note in the section where we introduce these variables for the first time, I think it makes more sense to put them there than in the conclusion.
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
…sbo.md Co-authored-by: Armel Soro <[email protected]>
/lgtm /hold Feel free to unhold if other reviewers are ok |
docs/website/blog/2022-06-30-binding-database-service-without-sbo.md
Outdated
Show resolved
Hide resolved
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/hold cancel
/override OpenShift Integration tests/OpenShift Integration tests |
1 similar comment
/override OpenShift Integration tests/OpenShift Integration tests |
@feloy: Overrode contexts on behalf of feloy: OpenShift Integration tests/OpenShift Integration tests In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
@valaparthvi: Overrode contexts on behalf of valaparthvi: OpenShift Integration tests/OpenShift Integration tests In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
* Blog: Connecting to a service without SBO Signed-off-by: Parthvi Vala <[email protected]> * Dharmit's review * Dharmit/Philippe's review * Use devfile variable substitution, and bitnami charts for deploying mongodb service * More review changes * Fix netlify failures * FIx broken links * Philippe's review * Show that odo dev will fail before adding connnection information Signed-off-by: Parthvi Vala <[email protected]> * Update docs/website/blog/2022-06-30-binding-database-service-without-sbo.md Co-authored-by: Armel Soro <[email protected]> * Fix port in the devfile, add note about env vars * Change port Co-authored-by: Armel Soro <[email protected]>
Signed-off-by: Parthvi Vala [email protected]
What type of PR is this:
/kind documentation
What does this PR do / why we need it:
Which issue(s) this PR fixes:
Fixes #5771
PR acceptance criteria:
Unit test
Integration test
Documentation
How to test changes / Special notes to the reviewer:
https://deploy-preview-5915--odo-docusaurus-preview.netlify.app/blog/binding-database-service-without-sbo