Hi, For the new "FIWARE Media & content lab" (aka FIC2 Lab) we exclusively use docker deployed within FIWARE Lab VMs. We use a dedicated set of VMs for the Tweak functionality and can do 1-click deployments of GEs and SEs (or groups thereof) to a dockerized VW of a FIWARE Lab user. We also offer instructions for users to deploy the functionality to private docker installations. All relevant FIcontent SEs (and needed FIWARE GEs) have been dockerized for this new offering of FIcontent. A few more will follow You can try FIWARE media & contet lab here: http://lab.mediafi.org/. Best, Philipp Am 08.07.2015 um 08:12 schrieb Federico Michele Facca: > hi philipp, > correct me if I am wrong fic2 developed a paas based on cloudfoundry. so > as such you are using containers in vms, > eventhough a different type of containers from docker. > > federico > > On Wed, Jul 8, 2015 at 7:46 AM, Philipp Slusallek > <philipp.slusallek at dfki.de <mailto:philipp.slusallek at dfki.de>> wrote: > > Hi all, > > This all sounds good! > > But what happened to your planned next meetings. FIC2 is still highly > interested in working with FIWARE to deploy the infrastructure developed > there (running on FIWARE Lab) also for FIWARE. > > I thought the idea was to explore these options in a joint next call. > > Best, > > Philipp > > Am 30.06.2015 um 22:05 schrieb Juanjo Hierro: > > 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 > <mailto: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 > <http://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 <mailto:glikson at il.ibm.com> | Phone: > +972-4-8281085 <tel:%2B972-4-8281085> | Mobile: > >> +972-54-6466667 <tel:%2B972-54-6466667> | Fax: +972-4-8296112 > <tel:%2B972-4-8296112> > >> > >> > >> > >> _______________________________________________ > >> Fiware-cloud-containers mailing list > >> Fiware-cloud-containers at lists.fiware.org > <mailto: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 > <mailto:Fiware-cloud-containers at lists.fiware.org> > > https://lists.fiware.org/listinfo/fiware-cloud-containers > > > > -- > > ------------------------------------------------------------------------- > Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH > Trippstadter Strasse 122, D-67663 Kaiserslautern > > Geschäftsführung: > Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) > Dr. Walter Olthoff > Vorsitzender des Aufsichtsrats: > Prof. Dr. h.c. Hans A. Aukes > > Sitz der Gesellschaft: Kaiserslautern (HRB 2313) > USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 > --------------------------------------------------------------------------- > > _______________________________________________ > Fiware-cloud-containers mailing list > Fiware-cloud-containers at lists.fiware.org > <mailto: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 <mailto:federico.facca at create-net.org> > T @chicco785 > W www.create-net.org <http://www.create-net.org> -- ------------------------------------------------------------------------- Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH Trippstadter Strasse 122, D-67663 Kaiserslautern Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender) Dr. Walter Olthoff Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes Sitz der Gesellschaft: Kaiserslautern (HRB 2313) USt-Id.Nr.: DE 148646973, Steuernummer: 19/673/0060/3 --------------------------------------------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: philipp_slusallek.vcf Type: text/x-vcard Size: 441 bytes Desc: not available URL: <https://lists.fiware.org/private/fiware-cloud-containers/attachments/20150708/7ec99bd0/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy