[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Dockerfile in OpenShift



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 <rcarvalh redhat com> wrote:
> Hi Den,
>
>
>
> On Fri, Jan 22, 2016 at 9:32 AM, Den Cowboy <dencowboy 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]