Whoah, wow. Many of us were out last week, sorry for delay. Can we
back up a second?
First, I may have misinterpreted what you were asking, if so I apologize.
Looking at your StackOverflow, you say:
```
I want the arguments called to match Docker:
docker run -it -p 8080:8080 joethecoder2/spring-boot-web
cassandra_ip=127.0.0.1 cassandra_port=9042
```
This runs the image "joethecoder2/spring-boot-web" with 2 args,
"cassandra_ip=127.0.0.1" and "cassandra_port=9042".
Your YAML uses the same image:
```
image: docker.io/joethecoder2/spring-boot-web
```
You set the command field, but I don't think you need to. It's baked
into your image (or so it would seem, since `docker run` works).
You only need to pass the arguments:
```
args: ["$(cassandra_ip)", "$(cassandra_port)"]
```
So why are these variables? Where are those variables being assigned?
A reply tells you to set them in the env sections, which is correct
(though they use teh wrong syntax for accessing - $(var) is good, $var
is not.
Later you say "the java arguments now execute within the Pod, however,
they execute only once" - I have no idea what that means. Arguments
do not execute.
On Mon, Dec 11, 2017 at 5:08 AM, 'Matt Brown' via Kubernetes user
discussion and Q&A <kubernetes-users@googlegroups.com> wrote:
> 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.
--
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.
