On Tue, Dec 5, 2017 at 11:54 AM, Alan Christie <
achris...@informaticsmatters.com> wrote:

> Thanks again, Ben.
>
> I run into two problems with your _alternative_ suggestion … it looked
> really promising because at least you have access to the pod configuration
> (in the Jenkins "Configure System->Cloud->Kubernetes”), which is cool, but
> I encounter the following in the Jenkins log as it attempts to launch my
> slave Pod...
>
> * Invalid value: true: Privileged containers are not allowed*
>
> That’s annoying, especially as there’s a checkbox for it. But also…
>
>
> * Invalid value: "hostPath": hostPath volumes are not allowed to be used*
>

You'll have to take that up w/ Kubernetes plugin maintainers:
https://plugins.jenkins.io/kubernetes

Hence my recommendation you use DOCKER_HOST instead.



>
>
> On 5 Dec 2017, at 15:48, Ben Parees <bpar...@redhat.com> wrote:
>
>
>
> On Tue, Dec 5, 2017 at 10:36 AM, Alan Christie <achristie@
> informaticsmatters.com> wrote:
>
>> Thanks Ben. It does seem sensible to use build strategies but prior to a
>> wholesale migration to OpenShift, and for existing workflows that may
>> contain docker and docker-compose commands is there any reasonable option
>> other than a an external (cloud/proprietary/dedicated) docker-enabled
>> slave? I can, for example, just have a Docker slave available (outside the
>> OpenShift cluster) but that’s not ideal.
>>
>> Is there an _unsafe_ route I might be able to use now?
>>
>
> use DOCKER_HOST env variable and point to a host w/ a public docker.
>
> The alternative is to try to use a hostpath volume definition in your
> slave pod template but then you also need to run the slave pod as
> privileged.
>
>
>
>
>> I understand the issues around sharing a docker.sock but it seems to be
>> an acceptable strategy for many. And, for a controlled environment, just
>> mounting docker.sock is a rather neat (quick-n-dirty) solution.
>>
>> It may be that, was you say there’s no sensible route down the
>> OpenShift/CICD road other than build strategies. It’s just that for
>> existing/legacy projects not having docker.sock is quite a hill to climb.
>>
>> Thanks for your advice though, that has been gratefully received.
>>
>> Alan.
>>
>> On 5 Dec 2017, at 13:41, Ben Parees <bpar...@redhat.com> wrote:
>>
>>
>>
>>
>>
>> On Dec 5, 2017 07:57, "Alan Christie" <achris...@informaticsmatters.com>
>> wrote:
>>
>> I’m using Jenkins from the CI/CD catalogue and am able to spin up slaves
>> and use an `ImageStream` to identify my own slave image. That’s useful, but
>> what I want to be able to do is build and run Docker images, primarily for
>> unit/functional test purposes. The _sticking point_, it seems, is the
>> ability to mount the host's `docker.sock`, without this I’m unable to run
>> any Docker commands in my Docker containers.
>>
>> Q. Is there a way to mount the Jenkins/OpenShift host’s
>> /var/run/docker.sock in my slave so that I can run Docker commands?
>>
>>
>> Not safely. (mounting the host docker socket is giving out root access to
>> your host).
>>
>> You could use a remote docker host with a certificate for access I
>> believe. (that's still handing out root access on the docker host but at
>> least it's a little protected)
>>
>> If not, what is the recommended/best practice for
>> building/running/pushing Docker images from a slave agent?
>>
>>
>> Define docker build strategies in openshift and trigger them from your
>> jenkins job.
>>
>>
>> Alan
>>
>> _______________________________________________
>> dev mailing list
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>>
>>
>>
>>
>
>
> --
> Ben Parees | OpenShift
>
>
>


-- 
Ben Parees | OpenShift
_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to