08-10-2020 01:54 PM
Hello everybody,
today I installed the newest IOS for the IR1101 and the remote Docker support is finally here.
I managed to get it working just by following the instructions on the iOX local manager and it is AWESOME.
It is so much easier to deploy, test and debug applications, I especially love being able to use docker volumes.
However, I don't understand how to deploy a container so that it restarts with the router; do I still need ioxclient?
Am I going to see my container in the list of installed apps?
Is the remote Docker support only for development and testing or for app deployment too?
@Emmanuel Tychon, please enlighten me!
Best regards
Silla
Solved! Go to Solution.
08-15-2020 10:47 AM
>>For example, the remote docker workflow web interface generates the docker command line switches needed to run containers remotely for my machine, I'd like to know which switches are needed when running a production container.
A: auto generated docker runtime options when creating a profile are just for development purposes with remote docker workflow. These auto generated options correspond the docker app profile that got created. You don't need to explicitly specify or carryover any of these auto generated options for production deployment. If you make use of any other docker run options apart from autogenerated ones, those you would need to pass along during app activation/installation in production deployment. Hope this is clear. We will add it to DevNet documentation if not already.
>>Why switch to /iox_data instead of /data
As you pointed we have also seen many dockerhub images using /data path for storage. This in some cases didn't work well with IOx infra utilizing same path (/data) for storing some app related files. Hence we made the switch. In anycase we don't recommend apps to explicitly hardcode the /data path in app, developers should use environment variable (CAF_APP_PERSISTENT_DIR) to obtain the persistent storage path. This env var approach will work well for apps deploying across different Cisco platforms where we can't guarantee same /data path for persistent storage. Hope this helps
08-12-2020 08:28 AM
Hello Silla -- Happy to see that you get it working. You are right that the Remote Docker Workflow is only for the developer willing to test their application on a gateway that is dedicated for development. This means, and you guessed it, that your stuff do not get started automatically as you reboot the gateway.
Thanks
Emmanuel
08-12-2020 09:04 AM
Ok, thank you, but it would be nice to use the remote docker workflow to connect to and to debug production apps.
I also noticed that while using the remote docker workflow, the data volume (the one that is also accessible via API) is mounted on /iox_data instead of in /data like it used to be on previous iOX versions. Is it going to be the same for productions apps too?
Is there some DETAILED documentation on how build native docker containers for production deployment? For example, the remote docker workflow web interface generates the docker command line switches needed to run containers remotely for my machine, I'd like to know which switches are needed when running a production container.
I've searched around but could not find much...
Thanks again!
Silla
08-15-2020 02:42 AM - edited 08-15-2020 03:51 AM
So, after some more digging, I can confirm that the persistent data volume is now mounted in /iox_data/appdata for production deployment.
That's good to know, but why? Most containers on docker hub save their data in /data...
In the meantime, release notes for IOS-XE 17.3.1 for the IR1101 are out and they contain some good pointers:
- Overview of remote docker workflow
- How to deploy docker apps: that is actually super easy, all you need is to "docker save" the container to a file and then upload it to the router, no package.yaml needed; if you need one, you can generate it automatically using ioxclient:
ioxclient docker package <dockerimage:tag> .
The interface to expose ports is not there anymore, as far as I can tell, so I needed to expose the port I needed using docker cli switches during activation, for example -p 1880:1880.
- Ultra-useful and super cool tips to cross develop for armv8 from x86, using the power of QEMU - Fabrice Bellard is my personal god
Best regards
Silla
08-15-2020 07:03 AM
Here are more new DevNet doc pointers.
Direct docker image deployment support:
https://developer.cisco.com/docs/iox/#!tutorial-deploy-dockerhub-image
Creating custom package.yaml
https://developer.cisco.com/docs/iox/#!tutorial-create-custom-package-descriptor-for-docker-apps
Docker compose yaml support on Cisco IC3000
https://developer.cisco.com/docs/iox/#!application-groups
Direct OVA based vm app deployment support on Cisco IC3000
https://developer.cisco.com/docs/iox/#!ova-to-iox-vm-app-package-deployment
08-15-2020 10:47 AM
>>For example, the remote docker workflow web interface generates the docker command line switches needed to run containers remotely for my machine, I'd like to know which switches are needed when running a production container.
A: auto generated docker runtime options when creating a profile are just for development purposes with remote docker workflow. These auto generated options correspond the docker app profile that got created. You don't need to explicitly specify or carryover any of these auto generated options for production deployment. If you make use of any other docker run options apart from autogenerated ones, those you would need to pass along during app activation/installation in production deployment. Hope this is clear. We will add it to DevNet documentation if not already.
>>Why switch to /iox_data instead of /data
As you pointed we have also seen many dockerhub images using /data path for storage. This in some cases didn't work well with IOx infra utilizing same path (/data) for storing some app related files. Hence we made the switch. In anycase we don't recommend apps to explicitly hardcode the /data path in app, developers should use environment variable (CAF_APP_PERSISTENT_DIR) to obtain the persistent storage path. This env var approach will work well for apps deploying across different Cisco platforms where we can't guarantee same /data path for persistent storage. Hope this helps
08-17-2020 12:30 AM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide