I wrote about 5000 lines of code this summer to complete the Google summer of code project of dockerization of OpenWISP and creating docker images of OpenWISP modules. The images are under alpha testing by the OpenWISP team on a kubernetes cluster. Some users have shown great interest in the project and tried out the alpha version of the images by themselves.
About the Project:
The current method to setup OpenWISP is using our Ansible-OpenWISP2 script. It works well but has some limitations like lack of support for horizontal scaling. The script is a considerable maintenance effort because of different dependencies & installation methods in different Linux distributions which limits our support to only selected distributions.
To tackle these problems, we decided to make OpenWISP modules available as plug-and-play docker images with all the supporting services to have a fully functional OpenWISP instance on a single machine or a cluster. The docker images are suited for complex deployments that need horizontal scaling, custom setups and easily replicable deployments making OpenWISP highly scalable and quick to deploy even for large and complex networks.
Some Special features:
- Easy Customisation & Setup
The OpenWISP docker images are easy to setup and designed with customisation in mind to ensure that users can easily tailor these images for their network and existing infrastructure.
We have made the docker images of the supporting services of OpenWISP including the images for Postfix Mail Server, FreeRADIUS, PostgreSQL, Nginx and OpenVPN to have a complete package ready with batteries-included.
- Tailor Build
It is easy to build tailored OpenWISP images. Users can either use the official images as base or make a fork of the repository and use the docker-compose file by following the image building instructions to make tailored images effortlessly.
- Out-of-the-box OpenVPN
The new installation procedure comes with a default OpenVPN server that can be customised right from your OpenWISP dashboard. It makes having the management VPN quick and easy.
Images available for users:
We started the project with the idea that users should only need to scale the OpenWISP modules that needs to handle more traffic. So, we created 5 images for the OpenWISP modules openwisp-dashboard, openwisp-controller, openwisp-websocket, openwisp-topology and openwisp-radius.
- openwisp-dashboard: The heart of the operations, this image contains the admin interface to interact with OpenWISP web interface.
- openwisp-controller: All the controller API for the devices (Access Points) to communicate with OpenWISP dashboard.
- openwisp-radius: All the radius API for the users to authenticate & authorise.
- openwisp-topology: All the network-topology API for devices to communicate with OpenWISP.
- openwisp-websocket: Enables users to know the real-time location of their mobile devices.
- openwisp-nginx: An nginx image ready to serve the OpenWISP modules to users and enable internal communication between the images.
- openwisp-openvpn: An OpenVPN server instance in sync with OpenWISP default VPN server with a template ready to be added to devices out-of-the-box.
- openwisp-freeradius: An instance of freeradius connected to OpenWISP, and ready to be used with users’ custom settings.
- openwisp-postfix: Custom postfix instance configured to send information like signup mail, password reset mails to OpenWISP users.
Now, If the controller module needs to scale up because a lot of devices want to communicate to OpenWISP, the user will add an instance of openwisp-controller to accommodate the requirement. This break-up of the OpenWISP modules allows users to efficiently scale up according to the network needs without wasting resources.
The following work was done during the Google Summer of Code 2019:
- Repository: github.com/openwisp/docker-openwisp
- Docker Images: hub.docker.com/u/openwisp
- Pull Requests: bit.ly/GCommits
- Commits: github.com/openwisp/docker-openwisp/commits/master
I believe a task is worth the time and the experience is worth the effort when I can check the 3 boxes of ‘GPS’.
Goal: Goal of any project is what makes it worth spiritually: the goal we achieve during the Google Summer of Code is phenomenal. I was able to work on real world project that is going to be used by developers all over the globe. We extended the usability of OpenWISP and reduced the effort of deployment. GSoC provided an opportunity to do very impactful work for the OpenWISP project during my college days.
People: I worked with Andrew Stanley (@2stacks), Federico Capoano (@nemesisdesign) and Marco Giuntini (@hispanico). A special thanks to my mentors for taking their time out to guide me with knowledge to structure, design and complete the project. It’s really fun to work with @2stacks. Thanks to his expertise with cloud technologies, he always has the precise tools & information that is required to complete the task at hand. Thanks to @nemesisdesign for taking time out to help me understand and design the project properly and thanks for @hispanico, @nemesidesign and @2stacks for reviewing the tasks and providing the valuable comments and corrections to make the project a success.
Skills: I gained a lot of skills during the project. I learned the basics about cloud technologies and DevOps tools like Kubernetes, Terraform and Rancher. More importantly, it was an opportunity for learning to write maintainable code using the best practices while working with a remote team. I gained a lot of big and small skills relating to debugging and deployment which help me boost my confidence in my problem solving skills.
Hence, Google summer of Code was an amazing experience. Thanks for the Google Open-Source team for organising such an empowering program to help University students gain remarkable skills, meet amazing people and achieve incredible goals.
During the development of the project, we realised a couple of features which we think are going to be great addition to the project:
- Using selenium for CI testing to make our tests more robust: The shell script tests have proven to be unreliable in some cases.
- The Let’s Encrypt http01 verification has been implemented, but we think having dns01 verification would be very useful and hence it’s now in our road map for the project.
We will be soon getting ready for the beta release of the docker images and moving these images from staging environment to production environments. We can’t wait for the users to try out the beta releases and give us feedback. If you need more information or want to communicate, please feel free to reach us with links available here.
I hope this gives some insight into the project. Good luck with your project!