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 <[email protected]> wrote: > Hi Den, > > > > On Fri, Jan 22, 2016 at 9:32 AM, Den Cowboy <[email protected]> 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 [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/users
