Terraform.io may also be an option.  I've had some success with it and
Docker/Ansible and it has support for Kubernetes.

On Tue, Mar 26, 2019, 1:56 PM Marco Giuntini <[email protected]>
wrote:

> Hi,
>
> https://github.com/ansible/awx is not a tool but it is an example on how
> Ansible AWX project uses docker and ansible to deploy and configure the
> application.
>
> Regards,
>
> --
> Marco Giuntini
> GTalk: [email protected]
> Skype: hispanico70420
> Twitter: @Hispanico81
> PGP Key ID: BD774009
>
>
> On Tue, 26 Mar 2019 at 17:25, Federico Capoano <[email protected]>
> wrote:
>
>> A demo on Kubernetes and using some kind of tool that makes it easy to
>> provision (Marco Giuntini suggested https://github.com/ansible/awx, if
>> you know something equivalent you could suggest) would be a big win.
>>
>> Helping out in writing tests (using some sort of mock SSH server) for
>> https://github.com/openwisp/openwisp-controller/pull/31 is also a big
>> plus, because if the students really understand the code of that branch it
>> will have an easier time to understand how to deploy it, I have some
>> automated test samples that I can show if needed.
>>
>> Federico
>>
>>
>> On Tue, Mar 26, 2019 at 11:31 AM Ajay Tripathi <[email protected]>
>> wrote:
>>
>>> Hi,
>>>
>>> On Monday, March 25, 2019 at 7:25:05 PM UTC+5:30, Federico Capoano wrote:
>>>>
>>>> Yes, but we also want to allow to scale horizontally more easily, so
>>>> the traffic can be dispatched to more instances of the same containers if
>>>> needed (imagine a kubernetes cluster spread on multiple nodes).
>>>>
>>>
>>> Great. I made a docker swarm stack and tested horizontal scaling of my
>>> prototype of the docker-compose. I understand the requirement better now.
>>> **The mentioned docker-compose stack is a simple openwisp container and
>>> a redis container.
>>>
>>>
>>>> The Admin interface is used ony by administrators, not very often, so
>>>> we likley won't need more instances of the same containers to scale.
>>>> The load on the other services increases with the size of the network
>>>> (number of devices or also number of users in the case of the radius
>>>> module), so we will need to scale up with those.
>>>>
>>>
>>> Thanks for clearing that up.
>>>
>>>
>>>> each module has its own URLs and APIs that are not admin related which
>>>> are used to provide configurations, update the network topology,
>>>> communicate with freeradius and so on, each one of these group of features
>>>> should run in isolation.
>>>>
>>> A more realistic scenario is a user who wants to use only admin + radius
>>>> module, or admin + controller module.
>>>> But we should not add restrictions on which containers the users want
>>>> to use because we should consider this to be a base on which users and
>>>> developers can build a solution tailored to their needs with custom 
>>>> modules.
>>>>
>>> django-channels is the framework with which you build the websocket
>>>> server, but the actual logic that allows you to do anything with the
>>>> websocket is in OpenWISP.
>>>> At the moment only OpenWISP Controller has some websocket logic
>>>> (inherited from django-loci) but in the future we will have more.
>>>>
>>>
>>>> The duty of this container is to serve the websocket server and process
>>>> data coming from websocket clients.
>>>>
>>>> Immagine the same installation we have today, but instead of having it
>>>> on a single VM, we have it spread on different containers, each container
>>>> dedicated to a single service: the containers which receive more traffic
>>>> can be scaled up, either vertically with more resources (RAM, CPU) or
>>>> horizontally with more containers if possible (if a load balancer in front
>>>> of the containers is available to distribute traffic, we can do this with
>>>> nginx for all the containers which serve HTTP or WebSocket requests, with
>>>> the celery containers we don't need a load balancer because they read from
>>>> the broker service which in our case is redis by default).
>>>>
>>>
>>> That explained some crucial points to help me understand! :)
>>>
>>>
>>>> I hope is clearer now!
>>>>
>>>
>>> Yes, thank you.  Currently, I am reading more on the same. :)
>>> I am making a prototype with some of the features for understanding
>>> further, I am working on the features in whichever order I feel is most
>>> important for complete understanding.
>>> Please let me know if there is a specific requirement of the prototype
>>> that you'd like to see before the deadline so that I can focus on that
>>> first.
>>>
>>> Ajay
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "OpenWISP" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to [email protected].
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "OpenWISP" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "OpenWISP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenWISP" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to