Your "two cents" is very important to us. In fact, we welcome feedback from all, since we are now identifying the current limitations of hosting docker on the FIWARE Lab. Our target audience is developers familiar with docker that are creating services based on the FIWARE GEs . The use case is that they remotely manage their docker hosts and containers with local docker clients. Our design objectives are: Maximise the management capabilities; Enable automation; Make the user experience as frictionless as possible; Hide the underlying infrastructure, i.e. Openstack, so that developers won't need to learn yet another paradigm; Promote more efficient resource utilisation from the provider's point of view, i.e. FIWARE Lab; Allow other Docker DevOps tool sets to easily interact with the FIWARE Docker hosting infrastructure; etc. (your input is welcome) responses to your ps: >do we really need 1 docker vm for 1 user? That is the current state, but we need to do better. At least we need to expand the usage to the level of an organization with many members. >(or actually do we need VMs?) Bare metal and more efficient multi-tenancy will be in our road map, but we need to walk before we run. >Usage scenario #2.3, is this related to current limits of neutron w.r.t. docker-scheduler in OpenStack? We need to investigate further, but I don't think this is an OpenStack limitation, rather it looks like a limitation in docker-machine's OpenStack driver. Best Regards, Kenneth Nagin Ph: +972-4-8296227 Cell: 054-6976227 Fx: +972-4- 8296114 http://researcher.ibm.com/view.php?person=il-NAGIN From: Federico Michele Facca <federico.facca at create-net.org> To: Kenneth Nagin/Haifa/IBM at IBMIL Cc: fiware-cloud-containers at lists.fiware.org Date: 07/07/2015 04:58 PM Subject: Re: [Fiware-cloud-containers] FIWARE developer experience with Docker hi guys, i think the introduction of docker is a very interesting evolution of fiware offer. my two cents (following also some remarks from the commission) is that whatever is done needs to take into consideration the user experience and making life easier for the developer. - most of the complexity (unless the developer is really interested into getting into it) should be hidden to him (maybe this simply means more pre-cooked food / recipies for him in the blueprint/murano engine); - maybe we can learn from paas that are successful: can we have a docker environment for 2-3 development platforms/frameworks (django, ruby-on-rails) and simplify allow developers to deploy their code on it from a github repository? more things are possible (natting like in cloudfounfry and automatic dns registration) that may improve the experience, i am just brainstorming :) some of the things can be pushed as well to WP2.1. hope it helps! fede PS: do we really need 1 docker vm for 1 user? (or actually do we need VMs?) c.f. Usage scenario #2.3, is this related to current limits of neutron w.r.t. docker-scheduler in OpenStack? On Tue, Jul 7, 2015 at 3:36 PM, Kenneth Nagin <NAGIN at il.ibm.com> wrote: The Cloud chapter has already begun focusing on providing Docker support. 1. IBM is preparing a study of how FIWARE developers can leverage the current FIWARE lab to host Docker while using Docker ecosystem tools locally to develop and deploy their applications. We will verify 1) Docker-Engine and Docker-Machine for setting up their remote hosting environment, 2) Docker-Compose for constructing and running multi-container applications hosted on FIWARE, 3) Docker-Swarm for host clustering and container scheduling. (Issue CLD-574). The output of the study will be to describe the capabilities, limitations and gaps of hosting Docker on FIWARE. We presented preliminary results at the sprint closing chapter review (Monday July 6). 2. IBM documented the required set up by a FIWARE developer for hosting Docker on FIWARE. This documentation is available at http://www.slideshare.net/knagin/simple-docker-hosting-on-fiware-lab. (Issue CLD-576). This is basically the outputs of <1> and can be contributed to item <2> in Juano's attached note. We are currently studying the limitation of this environment and a roadmap to address these limitations . We will share it with the task force once it is completed. 3. TID is preparing a demonstration of Murano Docker Support (Issues CLD-560, CLD-568 ). This would allow a FIWARE developer to deploy Docker containers using the Murano API. Henar will demonstrate deploying docker with Murano at the sprint closing chapter review (Monday July 6). 4. UPM is estimating the work effort to expose the Murano to the user on the cloud portal. This involves adapting the current blue print views to the Murano API (Issue CLD-584). Best Regards, Kenneth Nagin Ph: +972-4-8296227 Cell: 054-6976227 Fx: +972-4- 8296114 http://researcher.ibm.com/view.php?person=il-NAGIN From: Juanjo Hierro <juanjose.hierro at telefonica.com> To: Alex Glikson/Haifa/IBM at IBMIL, < fiware-cloud-containers at lists.fiware.org> Date: 30/06/2015 11:06 PM Subject: Re: [Fiware-cloud-containers] FIWARE developer experience with Docker Sent by: fiware-cloud-containers-bounces at lists.fiware.org Dear all, Thanks Alex for launching these discussions tracks. Regarding point (1) as anticipated by Alex, here it is the concrete plan we aim at implementing to promote usage of docker tools by GE/SE owners and the broader developer community. 1. Make info about Docker images and instruction to setup docker containers linked to FIWARE GEris available in the FIWARE Catalogue: We will specify a general template of a new section which will be included in the "Creating instances" tab of entries linked to FIWARE GEris. This section will be elaborate on "Deploying a dedicated GE instance using Docker technology" Each FIWARE GEri owner will be asked to setup a Docker image for their GEs and register it in Docker Hub. This task can start in parallel to the previous one. Each FIWARE GEri owner will be asked to update the "Creating instance" tab of the entry linked to the FIWARE GEri so that it provides instructions about deploying a dedicated instance of the GEri using docker. For this purpose, the owner will follow the template defined in step 1. 2. We will incorporate the description about how to create FIWARE GEri instances and try them using docker within the FIWARE Tour Guide for developers (which will effectively become the landing page of http://developers.fiware.org) as a mean to shorten the learning curve with FIWARE GEris Somewhere at the beginning of the guided tour, we will explain the developer how he can setup the basic docker environment either locally or on the FIWARE Lab on which he will be able to rely to try the different FIWARE GEris (Group 1 scenarios described by Alex) A demo application will be developed that will help the developer to try each FIWARE GEri instance deployed using docker with concrete data. Developers will be able to deploy this application also using docker. It is the intention that this application will be helpful to show how several FIWARE GEris can be used in an integrated way. Each of the chapters of the FIWARE Tour guide for developers will integrate a "Try it yourself" section which will help the developer to create an instance of the FIWARE GEris referred in the chapter and try them. In addition, developers will be able to deploy the demo application, in order to learn from a more elaborated example how the FIWARE GEris can be used, and providing instructions about how to play with the FIWARE GEris, also "tweak" the application. Deployment of integrated FIWARE GEris and the demo application will be made feasible using docker composition tools José-Manuel Cantera will drive the implementation of these concrete actions. Regarding point 2, Bitergia has already developed a first bundle of FIWARE GEris deployable using Docker compose (as a whole or individually). They will work in extending this bundle integrating additional FIWARE GEris in collaboration with the corresponding FIWARE GEri owners. Bitergia and the ULPG will work together in the development of a first version of the demo application. Eventually, additional partners might be incorporated as additional skills and/or resources are needed. We will address first those scenarios dealing with local deployment, then we will incorporate those related to deployment on other infrastructures such as the FIWARE Lab as soon as the necessary preliminary work and/or detailed guidelines are completed (this would be done under coordination by Alex and I assume we will leverage on experience developed in FI-Content2). Feedback is welcome. Best regards, -- Juanjo ______________________________________________________ Coordinator and Chief Architect, FIWARE platform CTO Industrial IoT, Telefónica email: juanjose.hierro at telefonica.com twitter: @JuanjoHierro You can follow FIWARE at: website: http://www.fiware.org twitter: @FIWARE facebook: http://www.facebook.com/pages/FI-WARE/251366491587242 linkedIn: http://www.linkedin.com/groups/FIWARE-4239932 On 30/06/15 20:34, Alex Glikson wrote: Dear partners, Following the initial discussion at the containers task force, we identified two follow-on (related) discussion tracks: 1) expected FIWARE Lab user/developer experience with Docker 2) Enhancements to FIWARE Cloud Hosting architecture to support Docker (and enable requirements derived from #1) This email refers to topic (1). I will try to summarize the initial set of usage scenarios that we may want to support. We can then iterate on this over email, and have a phone call if needed, when we feel that we are close to a convergence point. Please, notice that I've subscribed several additional people relevant for the discussion (who could provide input related to UI, developers perspectives and operations perspectives). Assumptions: Notice that a prerequisite for all the usage scenarios is that all the FIWARE GEs (and SEs) are packages as Docker images and are kept in a central repository, preferably the docker hub (under a 'to-be-created' "fiware" namespace). Also, there is an assumption that the users/developers would want to work with Docker tools as much as possible (surfacing some or all of the capabilities via the FIWARE Cloud Portal too). Juanjo will elaborate on the approach we are thinking of to promote this with GE/SE owners and the broader developer community. Group 1: Basic Docker environment setup Usage scenario #1.1: A user wants a local Docker runtime on his laptop. He follows the standard instructions on setting up a docker host (e.g., running within a VirtalBox VM, using docker-machine / boot2docker) Usage scenario #1.2: A user/developer wants to deploy a dedicated Docker VM on FIWARE Lab (where he would then run various Docker containers). He uses the standard docker-machine tool, specifying the URI of the OpenStack Keystone in FIWARE Lab (and additional parameters, as needed). The tool creates a VM using standard OpenStack APIs (natively supported by FIWARE Lab) and configures Docker within the VM. The VM would need to have a public IP (naturally). Group 2: Basic life cycle of individual containers running GEs/SEs Usage scenario #2.1: A developer wants to publish (a version of) a GE/SE. After he is done creating the new Docker image, he pushes the new version of the GE/SE to Docker hub under corresponding FIWARE namespace (e.g., fiware/GE/cb-orion). Now the 'latest' version of the image points to the new version. Usage scenario #2.2: A user/developer wants to deploy locally an instance of a certain GE/SE. He uses the standard docker CLI to locally provision a container, referring to the corresponding image at Docker hub -- e.g.: "$ docker -H boot2docker-vm:2376 run fiware/GE/cb-orion" Usage scenario #2.3: A user/developer wants to deploy an instance of a certain GE/SE within his Docker VM on FIWARE Lab He uses the standard docker CLI to provision a container, referring to the location of his Docker VM as well as the corresponding image at Docker hub -- e.g.: "$ docker -H mydocker-vm37.lab.fiware.org:2376 run fiware/GE/cb-orion". ISSUE: the user would need to open the corresponding firewall ports in his VM (same as those of the GE/SE, or following the mapping performed during container provisioning) in order to make the GE/SE accessible. Ideally, this should be done in a scalable but secure manner. An easy solution is to open up-front (during VM provisioning) a range of ports (via setting up corresponding security group). A more advanced solution is to update the security group dynamically. Usage scenario #2.4: A user/developer wants to update a container comprising certain GE/SE with the latest version recently published in the dedicated namespace of the Docker Hub. He pulls the latest version from the Docker Hub, kills the old container, and starts a new one (attaching to the same resources). Note that this would work well when the application is properly designed for Docker (e.g., the container itself is stateless), and when the previous version of the container has been provisioned manually (as in #2, #4 above) by the developer (and he knows which resources to connect to). Group 3: Support for 'bundles' of GEs/SEs that together perform a certain complex function Usage scenario #3.1: A developer wants to publish (a version of) a 'bundle' of GEs/SEs that together perform a certain complex function. He creates a 'template' (e.g., following the format of docker-compose), referring to the individual GE/SE images as well as their interdependencies (e.g., links) and other composition properties. This might be done using a text editor, a Web UI provided by the FIWARE Cloud (conceptually similar to today's UI for creation of blueprints), or other tools from Docker ecosystem. He then uploads the template to the centralized templats repository. Note: it is likely that docker-compose will be able to use Docker Registry/Hub as a repository for templates (including versioning, push/pull, etc). Usage scenario #3.2: A user wants to provision locally a set of GEs/SEs, using a pre-defined template (comprising a 'bundle') He uses the standard docker-compose tool referring to the 'template' artifcat as well as the local Docker URL. Usage scenario #3.3: A user wants to provision a set of GEs/SEs in FIWARE Lab, using a pre-defined template (comprising a 'bundle') He uses the standard docker-compose tool referring to the 'template' artifcat as well as the target Docker URL in FIWARE Lab. Alternatively, he uses the FIWARE Portal UI to do the same (e.g., with Murano backend invoking docker-compose). Usage scenario #3.4: A user wants to update his Docker environment (local or on FIWARE Lab) with the latest version of a certain 'bundle' Note: may require enancements to docker-compose Group 4: Advanced scenarios Usage scenario #4.1: A user/developer wants to provision a cluster of VMs on FIWARE Lab that would host his Docker cluster (managed with Swarm or Kubernetes) He uses corresponding Murano/Heat template to provision the VMs and to configure the Docker/Swarm/Kubernetes cluster. Usage scenario #4.2: A user/developer wants to access a global instance of a Docker service in FIWARE Lab (shared, scalable, managed), so that he doesn't need to manage the corresponding VM(s) by himself. He authenticates with FIWARE Lab, and starts accessing the FIWARE Lab Docker API endpoint with the standard Docker tools or FIWARE-specific tools (as outlined above ). Usage scenario #4.3: A user/developer wants to manage access control for Docker images among FIWARE Lab users. He starts using the Docker Registry/Hub deployed within the FIWARE Lab. Notice that this is a very initial list -- I am sure that there are many inaccuracies and gaps. Feel free to comment. Thanks, Alex ==================================================================================== Alex Glikson Manager, Cloud Infrastructure Solutions, IBM Haifa Research Lab Email: glikson at il.ibm.com | Phone: +972-4-8281085 | Mobile: +972-54-6466667 | Fax: +972-4-8296112 _______________________________________________ Fiware-cloud-containers mailing list Fiware-cloud-containers at lists.fiware.org https://lists.fiware.org/listinfo/fiware-cloud-containers Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição _______________________________________________ Fiware-cloud-containers mailing list Fiware-cloud-containers at lists.fiware.org https://lists.fiware.org/listinfo/fiware-cloud-containers _______________________________________________ Fiware-cloud-containers mailing list Fiware-cloud-containers at lists.fiware.org https://lists.fiware.org/listinfo/fiware-cloud-containers -- -- Future Internet is closer than you think! http://www.fiware.org Official Mirantis partner for OpenStack Training https://www.create-net.org/community/openstack-training -- Dr. Federico M. Facca CREATE-NET Via alla Cascata 56/D 38123 Povo Trento (Italy) P +39 0461 312471 M +39 334 6049758 E federico.facca at create-net.org T @chicco785 W www.create-net.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.fiware.org/private/fiware-cloud-containers/attachments/20150708/7c09b344/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy