Henry, to go back to the root of your question, I don't think you are having a problem with Docker or Kubernetes or the Datastax driver.
Your problem fundamentally is how to tell your application what IP and port to connect to for the Cassandra host(s). You get a NoHostAvailableException because you are hardcoding an address of 127.0.0.1:9042 (in your singlePod.yaml example) but you do not have a Cassandra server at that address (localhost) inside the application's pod. I suggest taking a step back and looking at the problem as "how should my application discover what Cassandra hosts to connect to at startup time?". You can certainly hardcode this in the pod yaml if you think that the Cassandra contact points will never change. Other options you have for this are service discovery systems, DNS/SRV queries, etc. If your Cassandra instances are running in Kubernetes then you might get some mileage out of creating a Service and doing SRV queries in the application pod. At the end of the day though, this is a decision to make at the application layer, and not something Kubernetes/Docker/Datastax can decide for you. On Sunday, December 10, 2017 at 12:29:29 PM UTC-5, Henry Hottelet wrote: > > Rodrigo, > > I am going to do a remote test with Docker, however it has to be mapped to > a public IP address. At that point, the REST service, is mapped to a > remote IP and port, which means that at that point, it doesn't matter if > Cassandra runs in docker or not. > > However the question, still remains about whether springboot and datastax > driver can run inside a docker container and target a remote ip and port. > > I would have to do some stand alone tests to find out. > > Do you know if anyone else is running Pods that target a remote database > service? > > -Henry > > On Sunday, December 10, 2017 at 12:23:57 PM UTC-5, Rodrigo Campos wrote: >> >> Okay, so that's not at all related with what I've said... >> >> I'm quite sure that port is fine regarding docker Kubernetes, don't know >> about your driver. Wild guess: might be just not using SO_REUSE or >> something like that in your local machine what you think it's the issue. >> >> Good luck with that >> >> On Sunday, December 10, 2017, Henry Hottelet <hott...@gmail.com> wrote: >> >>> Rodrigo, >>> >>> I have decided to go down another path, and consider Dynamic changes to >>> IPaddress and Port numbers via REST interface calls remotely into a Docker >>> image. >>> >>> Although configuring Pods at definition time, with arguments might be >>> cool, I have gone down another path, and am considering configuring >>> connection settings being dynamic at runtime via a configure interface. >>> >>> Preliminary tests, are showing me that Docker has a conflict with >>> Datastax driver on port 9042, with local IPaddress of 127.0.0.1 due to port >>> binding issues on a local machine. >>> >>> I am investigating further to help determine if these restrictions can >>> be lifted for DataStax driver support inside a docker container, which is >>> limiting me using Pods at all. >>> >>> I hope Datastax can help lift this restriction, however, I see it as a >>> current limitation on Docker and Datastax driver, and have opened an issue >>> with Datastax. ( >>> https://groups.google.com/a/lists.datastax.com/forum/#!topic/java-driver-user/QohK0Sd86-4 >>> ) >>> >>> If you were curious on how to recreate the problem with Docker and >>> DataStax driver: >>> docker run --name cassandra -m 2g -p 127.0.0.1:9042:9042 -p >>> 127.0.0.1:9160:9160 -d cassandr >>> docker run --name spring-boot-web -p 8080:8080 -p 127.0.0.1:9042:9042 -p >>> 9160:9160 docker.io/joethecoder2/spring-boot-web TCP4-LISTEN:9042 TCP4: >>> 172.17.0.2:9042 >>> >>> I have hit a deadend, at this point for using Docker and Datastax >>> driver, and I was hoping that they would work together, however the fall >>> back path is to use SpringBoot without Docker or Kubernetes Pods. >>> >>> Is anyone else currently using Data query calls from within Docker with >>> a database driver to an outside ip address and port? >>> >>> -Henry >>> >>> >>> On Saturday, December 9, 2017 at 11:29:58 AM UTC-5, Rodrigo Campos wrote: >>>> >>>> Google??? And, also, what is the point of that phrasing? >>>> >>>> Someone was trying to help, maybe there was some miscommunication and >>>> the suggested solution was not what better fits you now. That's all, right? >>>> >>>> On Thursday, December 7, 2017, Henry Hottelet <hott...@gmail.com> >>>> wrote: >>>> >>>>> *How to pass arguments to Kubernetes POD were succesfull, however >>>>> Google states, that templates are needed for configurability.* >>>>> >>>>> >>>>> https://stackoverflow.com/questions/47700482/kubernetes-pod-arguments-are-not-displayed-in-service-under-args-without-error/47703631#47703631 >>>>> >>>>> >>>>> On Thursday, December 7, 2017 at 11:27:23 AM UTC-5, Tim Hockin wrote: >>>>>> >>>>>> You want a template expander before you get to kubectl. Otherwise, >>>>>> the thing that is running isn't reflected by any versionable artifact. >>>>>> >>>>>> Because templating is a high-opinion space, we do not (currently) >>>>>> have one that is built-in. >>>>>> >>>>>> On Dec 7, 2017 10:12 AM, "Henry Hottelet" <hott...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> Is there not a way to pass arguments from command line to the Pod >>>>>>> specification? There should be, because this is not the first time >>>>>>> that a >>>>>>> Docker argument is needed when calling a Pod instance, whether dynamic >>>>>>> or >>>>>>> staticly defined. >>>>>>> >>>>>>> I could have Pod1.yaml, Pod2.yaml, and have an Ipaddress, and Port >>>>>>> number for reach separate Pod that is defined. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, December 7, 2017 at 11:03:28 AM UTC-5, Tim Hockin wrote: >>>>>>>> >>>>>>>> Kubectl is not a templating system, which is what you are asking >>>>>>>> for. Create/Apply are declarative plumbing, suitable to things you >>>>>>>> would >>>>>>>> check in to source control. There are porcelain commands, eg. kubectl >>>>>>>> run, >>>>>>>> which are closer to docker run, but less suitable to source control. >>>>>>>> >>>>>>>> On Dec 7, 2017 9:56 AM, "Henry Hottelet" <hott...@gmail.com> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> A problem: >>>>>>>>> >>>>>>>>> Docker arguments will pass from command line: >>>>>>>>> >>>>>>>>> docker run -it -p 8080:8080 joethecoder2/spring-boot-web >>>>>>>>> -Dcassandra_ip=127.0.0.1 -Dcassandra_port=9042 >>>>>>>>> >>>>>>>>> However, when I do: >>>>>>>>> >>>>>>>>> kubectl create -f ./singlePod.yaml >>>>>>>>> >>>>>>>>> Kubernetes POD arguments will not pass from singlePod.yaml file: >>>>>>>>> >>>>>>>>> apiVersion: v1 >>>>>>>>> kind: Pod >>>>>>>>> metadata: >>>>>>>>> name: spring-boot-web-demo >>>>>>>>> labels: >>>>>>>>> purpose: demonstrate-spring-boot-web >>>>>>>>> spec: >>>>>>>>> containers: >>>>>>>>> - name: spring-boot-web >>>>>>>>> image: docker.io/joethecoder2/spring-boot-web >>>>>>>>> env: ["name": "-Dcassandra_ip", "value": "127.0.0.1"] >>>>>>>>> command: ["java","-jar", "spring-boot-web-0.0.1-SNAPSHOT.jar", >>>>>>>>> "-D","cassandra_ip=127.0.0.1", "-D","cassandra_port=9042"] >>>>>>>>> args: ["-Dcassandra_ip=127.0.0.1", "-Dcassandra_port=9042"] >>>>>>>>> restartPolicy: OnFailure >>>>>>>>> >>>>>>>>> Question: How do I correctly specify arguments that will change at >>>>>>>>> runtime? I want to add two arguments that change at Kubernetes POD >>>>>>>>> runtime, because these should be configurable for each POD that is >>>>>>>>> defined. >>>>>>>>> Arguments for the POD are: -Dcassandra_ip=127.0.0.1", >>>>>>>>> "-Dcassandra_port=9042 >>>>>>>>> >>>>>>>>> I want the arguments to be accepted just like the Docker command >>>>>>>>> line. >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "Kubernetes user discussion and Q&A" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to kubernetes-use...@googlegroups.com. >>>>>>>>> To post to this group, send email to kubernet...@googlegroups.com. >>>>>>>>> Visit this group at >>>>>>>>> https://groups.google.com/group/kubernetes-users. >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Kubernetes user discussion and Q&A" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to kubernetes-use...@googlegroups.com. >>>>>>> To post to this group, send email to kubernet...@googlegroups.com. >>>>>>> Visit this group at https://groups.google.com/group/kubernetes-users >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Kubernetes user discussion and Q&A" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to kubernetes-use...@googlegroups.com. >>>>> To post to this group, send email to kubernet...@googlegroups.com. >>>>> Visit this group at https://groups.google.com/group/kubernetes-users. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Kubernetes user discussion and Q&A" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to kubernetes-use...@googlegroups.com. >>> To post to this group, send email to kubernet...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/kubernetes-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
