Please, some prediction as to when the ‘Alternate Addresses and Custom Ports’ functionality (already available on JDK Java - https://docs.couchbase.com/java-sdk/current/howtos/managing-connections.html) will be available in the .NET SDK?
The .NET SDK already supports alternate addresses; custom ports is coming and there is a ticket for it. Its not assigned to a release yet, but likely in the Oct or Nov release.
Thank you very much for the quick response. Without the native implementation of the Alternate Addresses and Custom Ports features, is there any other way to connect to Couchbase available in a docker? I need these features in the CI / CD testing scenarios. Thanks for listening !
Please, how to use alternate addresses in the .NET SDK?
Can you describe your specific CI/CD scenario in a bit more detail? We use a containerized Couchbase instance in our CI/CD testing scenarios using the .NET SDK without the need for custom ports. It’s possible that I may be able to provide some pointers to help get you up and running in your pipeline.
At a high level, let me describe how we execute our tests, and once I understand your needs I may be able to provide more precise details that would assist you.
- Our tests are run by script that executes a docker-compose file
- The docker-compose file includes a minimum of 3 containers: Couchbase, the service under test, and a test execution container
- Couchbase is accessible directly via the service name in docker-compose. I.e. if the Couchbase container is named “couchbase” in the compose file, then “couchbase://couchbase” will connect to it. No port configuration is required
- We use a specialized Couchbase image called CouchbaseFakeIt that allows us to easily define buckets, indexes, eventing, and fake data to generate during container startup https://hub.docker.com/r/btburnett3/couchbasefakeit
This approach only has two significant limitations that I’m aware of:
- The service being tested must be containerized. If not, then some port forwarding would be required (but it still shouldn’t need custom ports)
- It assumes your tests are okay with a single node cluster. If you need a multi-node cluster, some additional scripting within docker-compose would be required. CouchbaseFakeIt also doesn’t currently support multi-node. I do have some examples of this that could be referred to, however.
Our scenario is as follows:
We intend to run our tests through the ‘Build Validation’ feature of Azure Devops (https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#build- validation);
Tests are running with the support of TestContainers (https://github.com/HofmeisterAn/dotnet-testcontainers)
The service being tested, at first, is not available in a container and runs with the asp.net core memory testing feature (https://docs.microsoft.com/en-us/aspnet/ core / test / integration-tests? view = aspnetcore-3.1)
As the tests will be executed on a build server and it can receive several execution requests, I thought about the need to use random ports for this.
Still, I found the approach presented with the docker-compose and couchbasefakeit scenario very interesting, could you please give an example?
Thank you very much,
@matthew.groves When I sent this info over to you a few weeks ago, did you happen to turn it into a more formal example? If not I’ll try to find some time to make one up, I just don’t want to reinvent the wheel unnecessarily.
@btburnett3, I don’t have a formal example no. It’s in my backlog to write a couple of blog posts: 1) integration testing with .net and couchbase, 2) deploying integration tests to ci/cd pipeline with github actions.
In the meantime, you can check out the github action I created for integration testing here: https://github.com/mgroves/MattsTwitchBot/blob/master/.github/workflows/prtests.yml
@Israel_Santiago I see you said you use Eventing, I assume you want to automate a CI/CD pipeline WRT Eventing.
Just a note right now you can not update a running Eventing handler via “pause / edit / resume” with the current REST APIs or Couchbase CLI. Pause/Resume is guaranteed not to miss an Event so it is the best way to update a running production function (however you need to use the UI right now).
If you need this functionality “pause / edit / resume” automated (via REST or CLI) please let me know your companies name and I might be able to prioritize this and get it in one of the next few point releases.
I don’t have a formal example to offer you at this time, however, I’m sure I’ll have one in the next few weeks. I’m actually giving a presentation at Couchbase Connect next month that will cover, among some other things, how we do our local development and CI testing against containerized Couchbase instances. Feel free to attend the virtual session, or if not I’ll send you links to the materials I develop when writing the presentation.
@Israel_Santiago Here is the example I mentioned for using docker-compose to run tests. With a bit of tweaking to avoid binding ports on localhost and using “-p” to avoid container name conflicts it should also support running multiple builds in parallel on the same agent.