-
-
Notifications
You must be signed in to change notification settings - Fork 23
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
Feature/auth and tls for brokers #179
Feature/auth and tls for brokers #179
Conversation
I have made a few local tests with the configs, for integration tests I lack some knowledge of the setup. We needed two docker containers like in the normal test cases where the brokers are configured with auth and or TLS. That doesn't seem to be that easy to me. Maybe you @lerenn have an idea? |
Thanks @magraef for your great work ! If that's okay for you, I'll add the brokers with auth/TLS to brokers on your PR. I'll just change the existing containers in test as if it works with the auth/TLS, then it'll work without them. Or I can add a dedicated test to test TLS with each broker by adding a authenticated/TLS version of each broker. I would go on the first one, but I would be interested on what you think about that. |
I think the "cleanest" option would be to set up a test suite specifically for this use case that runs a docker container for nats and one for kafka and then runs a simple test case with writing a message and reading a message against a broker that is secured with TLS and authentication. I don't think we should make the regular tests more complicated than necessary. I had started to build a test case and dont use the asyncapi_test.BrokerControllers(t) in the TestSuite and instead create new ones manually. But i dont know where the docker containers are created and builded. I also always change the host to localhost in asyncapi_test.BrokerControllers(t) so that I can get the test to run at all :P But I know that you are already working on the contributer documentation, so I think that will be clearer. |
Yes, sorry about that ! I'm using Dagger (a tool made by the guys behind Docker) for CI and tests so it is a bit different as a classic I think you're right, the specific test is better. If you want to take a look there is the CI script in If you prefer to do it, I won't complain obviously, but you've already done so much that seems normal to help on that :) |
I haven't used Dagger yet, but I'll take a look at |
I'll put it in draft until then, but do not hesitate to ask me if there is anything unclear about how I have done the Dagger part :) It maybe not the most clear/efficient way, and that's why I'm trying to change it in another MR. |
7ae5632
to
2e1e552
Compare
@lerenn Sorry about the force push; I messed up the rebase a bit. I have making progress working with dagger, and i like it. I had to make some changes and found a few things that are not optimal in my opinion, but I will add those details to the open dagger issue once Im finished with this one. Let me know if you're okay with that approach. If so, I can do the same changes for Kafka. Unfortunately, setting up TLS for Kafka isn't as straightforward as it is for Nats because Kafka prefers .jks files and I want to avoid using system commands to set up TLS cleanly. There should be support for PEM format, but its not that good documented. I will see if I can find a a good solution. Looking forward to your feedback. |
No problem @magraef for the force push ! That's your fork, so IMHO you do what you prefer 😉 I'll take a look as soon as possible! Every improvement is good to have. |
Hello @magraef ! Sorry, for the delay. I reviewed the change on the CI and I'm all good for this ! |
Hey @lerenn , thanks for your feedback. Here are then the corresponding changes I made for Kafka. Additionally I have added a test to check if Kafka is working properly in the You might have noticed that not all tests are in the test folder. I suggest we customize the dagger test so that all tests in the repository are executed with the command: Im considering simplifying local development. Currently, to run and debug tests locally, I always need to modify the hosts in the tests and start the necessary services locally. I have created a docker-compose file with the brokers, TLS and authentication. I'm not sure if there's a better approach with Dagger or if you've already found a better way. |
…afka.Reader and kafka.Dialer
* adjust natsjetstream.go consumer and streams must be configured *after* successfully creating the client
…sful kafka connection on creation like nats controller
a82db4e
to
c9335cc
Compare
Thanks for the improvements ! 💪 I do agree for the check on Kafka, and if there is any trouble, worst case is we switch the default behavior. For the local development, normally you just have to launch the test with dagger and in the Makefile, you can specify which test to run. However, it's a bit too much for now to pop a docker container for each test, so we should simplify it I think. We can discuss this further on another PR/issue if you want (I'm not against adding a docker-compose, if it's easier to develop with) :) I'll merge this one ! |
} | ||
|
||
// registerStream creates or updates a stream based on the given configuration at the broker. | ||
func (c *Controller) registerStream() error { |
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.
There is a problem here, examples are broken because it should be possible to use Streams without creating them. But this change made it mandatory, which will break some usages.
We should put back the stream registration as an option, i.e. put it back to WithStreamConfig
:)
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.
Ah yes, sorry. I had to move it from the WithStreamConfig
and WithConsumerConfig
function, because register a stream or a consumer requires a fully configured connection to execute. If the broker is secured with TLS and or Auth, we would necessarily require WithConnectionOpts
to be executed beforehand. I wanted to avoid that.
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.
No problem
js, err := jetstream.New(nc) | ||
// registerConsumer set consumer configuration for creates or updates a consumer based on the given configuration | ||
// at the broker. | ||
func (c *Controller) registerConsumer() error { |
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, this should be relocated in the WithConsumerConfig
…rresponding config was set via ControllerOption
@lerenn Great that there are the examples and that you have noticed that. But I think it would be better if we either write tests for the ConfigOpts or add a step in the ci to run the examples automatically. |
Yup, the nice person that proposed to add dagger to the Github CI/CD pipeline didn't add the examples and I missed it when I reviewed it. It should be there also, I'll add it to the test related issue :) |
It's merged ! Thanks again for your amazing work |
Add support of configuration of broker authentication and TLS. Should close #169