Re: Docker containers, vxcan and cangw

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

 



On 16 August 2018 at 06:55, Oliver Hartkopp <socketcan@xxxxxxxxxxxx> wrote:
>>> the Linux host. Additionally vcan's can be created inside the docker
>>> containers.
>>
>>
>> Yes vcan can be used inside a container, but you need to use
>> --network=host, which is a no-go for me.
>
>
> Really? I think using vcan's from the root/init/global/default/host
> namespace is no senseful option, right?
>
> AFAICS you never need --network=host for using CAN inside Docker.
>
>> I guess to be able to create
>> vcan iface's from within a container you need to run in privileged
>> mode, which i'm not that keen on.
>
>
> You can either create vcan's inside that namespace or you can create a vcan
> (in the init namespace) and move it to the (docker) namespace by assigning
> that CAN interface to that namespace. The same that I suggested on slide 20
> with real CAN interfaces.

Got you, i do not need vxcan to play with namespaces, vcan and can now
both support it.
I discovered NS very, very recently. And w/o manipulating them at the
low-level, I think my above comments stands "kind of right".
You cannot do much with vcan by just using the "docker" command line,
you need to get your hands "dirty" and use iproute2 to manipulate NS.

Going further wrt vxcan, I still need the "two plugs" of the vxcan
link to cross namespace boundaries at will, don't I?
I'm getting a bit confused now. I'll have to run some more experiments.
My understanding is that to connect N distinctly namespace'd (v)can
together, i need vxcan and cangw. cangw running in yet another
(possibly root) namespace.

>> To my surprised, it just worked! The biggest surprise was that docker
>> didn't complain about the non-IP nature of vxcan network interfaces.
>
> Good to know. I've done nothing with Docker so far - but I know about some
> colleagues that are thinking about a similar test setup too.

I would be interesting to talk with other people looking toward similar goals.

I have found a way to create a more user friendly 'experience' when it
comes to docker plugins. I can now install it with:
$ docker plugin create chgans/can4docker ...
$ docker plugin enable chgans/can4docker
$ docker network create -d chgans/can4docker ....

The plugin is not yet published, but AFAIU, it should be straight
forward to push it to docker store:
$ docker plugin push chgans/can4docker

In which case, end-users will be able to do:
$ docker plugin install chgans/can4docker ...
$ docker plugin enable chgans/can4docker
$ docker network create -d chgans/can4docker ...

My approach so far was to manually deploy and start the plugin
locally, but apparently, "native" plugins are just a sort of
degenerated docker image.

Chris



[Index of Archives]     [Automotive Discussions]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [CAN Bus]

  Powered by Linux