cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3741
Views
0
Helpful
6
Replies

IR1101, IOS-XE 17.3.1 and remote Docker workflow

silla
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

>>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

 

View solution in original post

6 Replies 6

Emmanuel Tychon
Cisco Employee
Cisco Employee

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 

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

 

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

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

 

>>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

 

Thank you!
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: