Open cliftonc opened 9 years ago
We are currently working on deployment with containers. We expect to deploy Sherlock and Watson inside the containers, but we may introduce another component on the host and/or modify Watson in order to obtain the externally mapped port used to access the service. We'd like this to be as seamless as possible, so hopefully not much special will be required, but we will fill in the details as we get this working.
Ok - if you need any input / real world testers be happy to pitch in.
We use docker for all of our application services and have settled on using nginx with a configuration addition of sevice name and port, followed by a restart whenever we add new services (doesn't happen every day so not really that big a deal).
Where this completely falls flat is in the ability to do canary releases of something and port management over time becomes a pita, so interested in seeing how you guys get on with this - I like the approach and think it has legs.
Hi Clifton,
I am going to begin working on this issue. I started at Datawire.io about a month ago and have become the owner lead developer of the Baker Street project. My goal is to get some more detailed answers to your questions very soon.
This next bit may not directly address your question, but it still partially applies. Currently I am doing some work with Baker Street on Kubernetes. The model I have used for the deployment is to bundle at least Watson and the target service into a single Pod (a Pod is a logical collection of Containers according to Kubernetes). The client service also runs inside of its own Pod but on that particular Pod there is only a single container. This design is something we're using for building a testing harness and is a bit more convoluted than is probably necessary in a real environment because we want to run very specific testing scenarios around failures.
That said, it seems perfectly reasonable to me that Watson, Sherlock and a service could all be bundled together on the same container with Watson and Sherlock effectively running in the background. In Kubernetes land we use the containers IP address in the server_url so that Watson publishes a routable address that other containers can access.
Hopefully that gives you a little information so you can start thinking about a Baker Street deployment a bit more for your infrastructure and I look forward to answering the rest of your questions shortly as well as addressing any new questions or concerns you might have.
Regards, Phil
Hi Clifton,
Following up specifically on your question about port mapping. The only port mapping that you need to worry about is the Container host -> Container mapping (the -p switch for docker run). When a Baker Street enabled app registers with the Datawire Directory it indicates the port it is available on which in turn means Sherlock rewrites HAProxy configs on the client side to add that service to the pool of available services for a given service name. From the consuming client perspective you don't need to know about port numbers since all traffic is going to be sent to localhost:8000/
Regards, Phil
We've also taken some time and built a template image project that can be used for easily enabling Baker Street alongside a service. Going one step further, I put together a little sample project:
Check them out:
One query, I don't understand what the deployment architecture would look like if your services were all deployed in containers, and how you would go about releasing new versions of services alongside old ones in this model.
I'm having a hard time visualising how the container model works in practice and where the service and client nodes are configured - e.g. a specific example of how it works if you have two services (A -> B) in containers talking to each other and you want to canary release B.