For the integration of existing developments into docker/kubernates we use part of the Diamond flow for a beamline under kubernates.
In particular we have realised our customisation where we put all the normalisable support we have for our INFN's beamlines.
The project is INFN EPICS IOC by cloning it:
git clone https://baltig.infn.it/epics-containers/infn-epics-ioc.git --recurse-submodules
The aim of this project:
- create a docker image with the device support needed for INFN beamlines that can be run in container.
- standardize and greatly simplify the way to instantiate iocs via simple yaml file
- have a common database (shared among INFN and Diamond)
- standardize the build system
The layout of this project is:
.
├── Dockerfile <-- docker file production
├── LICENSE
├── README.md
├── build
├── ibek-support <-- submodule with ibek device support
│ ├── ADAravis
│ ├── ADCore
│ ├── ADGenICam
│ ├── ADSimDetector
│ ├── IOCInfo
│ ├── LICENSE
│ ├── README.md
│ ├── StreamDevice
│ ├── _global
│ ├── asyn
│ ├── autosave
│ ├── build_support.sh
│ ├── busy
│ ├── calc
│ ├── easy-driver-epics
│ ├── iocStats
│ ├── lakeshore340
│ ├── make_global_schemas.sh
│ ├── modbus
│ ├── motor
│ ├── motorMotorSim
│ ├── motorNewport
│ ├── opcua
│ ├── pmac
│ ├── pvi-generate.sh
│ ├── quadEM
│ ├── schemas
│ ├── screen-epics-ioc
│ ├── sequencer
│ ├── sscan
│ ├── tests
│ ├── todo
│ └── zebra
├── ioc
│ ├── Makefile
│ ├── configure
│ ├── install.sh
│ ├── iocApp
│ ├── liveness.sh
│ ├── start.sh
│ └── stop.sh
├── menlo
│ ├── install.sh
│ └── menlo.ibek.support.yaml
├── requirements.txt
├── requirements_ec.txt
├── tests
│ ├── example-config
│ ├── example-ibek-config
│ └── run-tests.sh
└── user_examples
└── README.md
When we have to put an IOC in production we may have the following possibility:
- support already present in <ibek-support>
- support present as git project
- support not present at all → put in the condition 2
Use an existing support
If a support is present in <ibek-support>, it's very simple to use it just create a yaml that instantiates your device(s).
An example could be the following the following yaml newport.yaml. It instatiate a motor with 1 axis. This support implicitly assumes that this serial control is connected to a Ethernet2Serial server like a moxa that responds on address 192.168.190.56 and port 4001
ioc_name: rfmotors
description: RF motors
entities:
- type: motorNewport.SMC100CreateController
controllerName: NEWPORT001
P: "SPARC:RF:"
IP: 192.168.190.56
TCPPORT: 4001
numAxes: 1
- type: motorNewport.motorAxis
controller: NEWPORT001
M: "m0"
DESC: "Axis"
ADDR: 0
DLLM: -25
DHLM: 25
home: 1
start: 10
VELO: 1
Then we can test if simply having the docker image: baltig.infn.it:4567/epics-containers/infn-epics-ioc
docker run -p 5064:5064/udp -p 5064:5064/tcp -p 5065:5065/udp -p 5065:5065/tcp -it -v .:/epics/ioc/config baltig.infn.it:4567/epics-containers/infn-epics-ioc:local
A generic asyn motor OPI interface can be used to drive the motor. Motor OPIs Remember to add localhost to your phoebus
org.phoebus.pv.ca/addr_list settings:
org.phoebus.pv.ca/addr_list=localhost org.phoebus.pv.ca/auto_addr_list=false org.csstudio.trends.databrowser3/urls=pbraw://sparc-archiver.apps.okd-datest.lnf.infn.it/retrieval org.csstudio.trends.databrowser3/archives=pbraw://sparc-archiver.apps.okd-datest.lnf.infn.it/retrieval org.phoebus.olog.es.api/olog_url=http://sparc-olog.apps.okd-datest.lnf.infn.it/Olog org.phoebus.olog.api/olog_url=http://sparc-olog.apps.okd-datest.lnf.infn.it/Olog org.phoebus.logbook/logbook_factory=olog-es org.phoebus.olog.api/username=epics org.phoebus.olog.api/password=epics org.phoebus.channelfinder/channelfinder.serviceURL=http://sparc-channelfinder.apps.okd-datest.lnf.infn.it/ChannelFinder org.phoebus.applications.saveandrestore.client/jmasar.service.url=http://sparc-saveandrestore.apps.okd-datest.lnf.infn.it/save-restore org.csstudio.scan.client/host=http://sparc-scanserver.apps.okd-datest.lnf.infn.it org.csstudio.scan.client/port=4810
Once the IOC runs correctly as docker can be inserted in the EPIK8S configuration