oc describe svc NAME will show you the service mapping and backing endpoints. dig @masterip servicename.namespace.svc.cluster.local will show you what is in DNS
On Jan 25, 2016, at 8:12 PM, Srinivas Naga Kotaru (skotaru) < skot...@cisco.com> wrote: Is skyDNS responsible for this resolution? Where we can see all service entries and their associated IP addresses? Am trying to understand a little better on cluster wide name resolution and container —> external DNS communication -- *Srinivas Kotaru* From: <users-boun...@lists.openshift.redhat.com> on behalf of " ccole...@redhat.com" <ccole...@redhat.com> Date: Sunday, January 24, 2016 at 9:24 AM To: Den Cowboy <dencow...@hotmail.com> Cc: "users@lists.openshift.redhat.com" <users@lists.openshift.redhat.com> Subject: Re: Dockerfile in OpenShift In each container DNS is set up so that the name for each service is a resolvable address (which means normal network operations like ping, curl, etc can use the service name in place of the service IP). If you have a service called "db", every container is "linked" to that service. On Jan 24, 2016, at 4:39 AM, Den Cowboy <dencow...@hotmail.com> wrote: Hi Clayton, Can you maybe give an example with commands? I know how to create a service etc. But I don't fully understand "in every pod the name "db". > Date: Fri, 22 Jan 2016 13:49:38 -0500 > Subject: Re: Dockerfile in OpenShift > From: ccole...@redhat.com > To: rcarv...@redhat.com > CC: dencow...@hotmail.com; users@lists.openshift.redhat.com > > OpenShift and Kube already have the equivalent of "link" through > services. If you create service "db" in a namespace, in every pod the > name "db" resolves to the service IP or the endpoints (depending on > what kind of service you created) - so you don't need to directly > link, you can just use the hostname "db" as your remote endpoint. > > On Fri, Jan 22, 2016 at 4:55 AM, Rodolfo Carvalho <rcarv...@redhat.com> wrote: > > Hi Den, > > > > > > > > On Fri, Jan 22, 2016 at 9:32 AM, Den Cowboy <dencow...@hotmail.com> wrote: > >> > >> Thanks for the answers. I have 2 containers which need to work together: > >> they are started by: > >> > >> docker run -d --name "name1" test/image1:1 > >> > >> docker run -d -p 80:80 --name "name2" --link name1:name1 test/image2:1 > >> > >> > >> The images are created with Jenkins and Docker. They're pushed to a > >> private repository. I've pulled the images from the private repo so now the > >> images are on my OpenShift-server. > >> > >> So the first question is how do I have to perform the docker 'link' > >> command in OpenShift. > > > > > > > > > > Reading the docs in https://docs.docker.com/engine/reference/run/, seems > > that all the '--link' does is allow you to talk to another container by name > > when they're in the same bridge network. > > > > In OpenShift, you may map that setup to having a Pod with multiple > > containers, or you might want to have one DeploymentConfig and one Service > > per image, and you can reference services in the same namespace by name. > > > > In the first situation, you have the guarantee that the containers will be > > scheduled on the same node. > > The advantage of the second scheme is that you can easily scale your > > deployments, and each independently. > > > > It boils down to the relationship between your two images. > > > > If they are something like "mysql" + "phpMyAdmin", then the first option my > > suit you well. > > If you have two microservices that need to talk to each other, I'd recommend > > the second approach. > > > > > > > > > > > >> > >> > >> The second question is that I can't start a container from the image (I'm > >> on OpenShift Origin 1.1 on Centos7) > >> > >> oc new-app ec2-xxx:5000/test/image1:1 > >> > >> > >> specify --allow-missing-images to use this image name. > >> > >> The 'new-app' command will match arguments to the following types: > >> > >> 1. Images tagged into image streams in the current project or the > >> 'openshift' project > >> - if you don't specify a tag, we'll add ':latest' > >> 2. Images in the Docker Hub, on remote registries, or on the local > >> Docker engine > >> 3. Templates in the current project or the 'openshift' project > >> 4. Git repository URLs or local paths that point to Git repositories > >> > >> A manual pull from the image of the registry is possible. I'm using > >> selfsigned certificates: > >> > >> > > > > > > > > Since you're pulling the image manually, in this case you can safely run: > > > > oc new-app ec2-xxx:5000/test/image1:1 --allow-missing-images > > > > > > new-app doesn't inspect your local Docker images. That's because you might > > be running the oc client in a machine that has a Docker daemon and the given > > image, but that has no implication with the image existing in the OpenShift > > nodes where the image will be run. > > Specifying --allow-missing-images confirms that you will be responsible for > > ensure the image is available in the nodes, since it cannot be pulled from > > the internal registry nor DockerHub. > > You might want to look into importing your images to your internal registry > > as ImageStreams: > > > > https://docs.openshift.org/latest/architecture/infrastructure_components/image_registry.html > > > > > > > > -- > > Rodolfo Carvalho > > > > OpenShift Developer Experience
_______________________________________________ users mailing list users@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/users
