ION Linux Distribution

An operating system that comes with a contemporary toolkit that enables you to immediately begin utilizing modern technologies required to develop modern containerized applications.

Comment 2

Inspiration

Modern technology encompasses an extensive variety of tools and platforms, including databases, version control systems, development environments, and programming languages. Because there is so much variation, it can be challenging for both experienced programmers and novices to stay up to date with the existing potential of tools like git, docker and go.

There is a large number of simple techniques that could help those who want to refresh their technological arsenal. The goal of the project is to combine the maximum number of such methods within a single software complex to significantly accelerate the development of modern applications, the culmination of which is the GNU/Linux distribution centered around the DevOps platform.

Perhaps the technology does not quite correspond to the topic of the hackathon, but it can have its usefulness due to its direct connection to the docker.

What it does

An operating system and its accompanying infrastructure that let you begin development right away with the use of tools like git, docker, go and other constitute a comprehensive solutions. The following tasks can be completed with the help of the technical solution:

  1. There's no need to spend time looking for details on the contemporary stack.

By default, programs are installed on the system; no additional tweaks are needed to begin using them right away.

  1. The working environment allows you to start using modern tools right away.

Setting up a working environment is time-consuming, especially when it comes to the modern tech stack. The distribution in the base version contains docker, git and vscodium and a user-friendly terminal. Configurations in different programs allow them to better fit with each other and with the system in general. All this combined creates a sense of a holistic and comfortable environment for instant productivity.

  1. Infrastructure provides integrated registries.

The home of the distribution is a public instance of gitea. Gitea allows users to store the source code and includes a built-in docker registry and a working mirror with arch linux packages. As a result, the user is provided with an environment that has direct access to docker, both from the client side's usage and it's registry capabilities. These tools are well harmonized within the framework of the overall software solution and are conducive to their use.

  1. Templates and ready-made implementations

Since the distribution itself is centered around the DevOps platform, containerized solutions are a key part of it. On the platform, you can find ready-made templates for setting up the same infrastructure, as well as repositories with Dockerfile's, docker-compose examples, or scripts that use containerized applications to solve some other problems. The user has a number of ready-made examples that allow them to reuse the existing experience without starting the search from scratch.

How we built it, Challenges we ran into

The development of the distribution began about a year ago. The initial goal of the project was to obtain an independent system that would allow the necessary components to be modified in accordance with existing requests.

Initially, the system was centered not around the ISO image but around the process of modifying it. This led to the first repositories with infrastructure, a self-hosted registry for arch packages connected to the AUR, a system installer, and further - ISO image. These solutions made it possible to establish the first automations for rebuilding the distribution, a kind of pipeline mechanism for constant reinstallation to find more and more bugs.

The distribution was developed on its own domain, within the gitea instance. In the development process, such tools as git, docker and the programming language go were actively used. At some point, this led to the idea that you can also use your own domain to install and deliver applications; it would just be convenient in the first place.

By that time, I already had an implementation of the self-hosted arch package registry, which allowed the installation of packages from the 'AUR' inside the container, but it was not stable. The need to maintain an additional microservice, obtain certificates for the sub-domain, and create a sense of balance in a repository with infrastructure led to the basic version of the registry being integrated into gitea. A smaller number of infrastructure elements simplify maintenance; this approach made it possible to preserve the existing convenience of a self-hosted registry for arch packages without reducing the amount of convenient functionality.

The first arch registry implementation within Gitea was terrible. File server roughly attached to some random endpoint, pacman package manager was installed in the base Alpine version of the Docker image of the Gitea container, so that it would be possible to use the'repo-add utility. Literally an antonym of elegance in the software world. Although, even at that point, registry allowed you to solve the original task of installing arch packages from the same domain with git repositories and Docker containers, keeping the development process convenient

Accomplishments that we're proud of

In the end, it led to the creation of an absolutely unique combination of technologies that literally have no analogs at the moment. The funny thing is that this happened almost by accident—a set of technological solutions literally grew into each other, covering some minor problems.

Even taking into account the fact that at the moment the technological implementations are extremely crude and the final concepts of their combination are already valuable, I am absolutely sure that it is necessary to test in practice the possibility of their utilization, although their very appearance is nothing more than mere luck.

Luck is not a reason to be proud, but the very fact that I have been literally living this project for the last year makes me feel proud.

What we learned

The devil is in the details. The main thing is to constantly look for these little things and work to improve them. By putting this process on a conveyor belt, you can significantly increase the chances that you will be able to bring something useful to the final process.

For example, I didn’t like the fact that I needed to renew the certificate for a subdomain, although the links were almost identical: ion.lc/repo.ion.lc. Only 5 characters—I would say that this is a small detail. However, an attempt to improve this little thing ultimately led to additional functionality in a large project, which seems to me to be a very positive result.

What's next for ION Linux Distribution?

I would be very grateful if you gave me the opportunity to present my project at the hackathon. If it doesn’t quite fit the topic, then I would be extremely grateful if you could suggest a place where I could turn for support.

I am absolutely convinced that it is necessary to utilize the existing capabilities of existing open solutions to optimize all possible processes. At least some of the concepts presented in my work could find practical application. I would be extremely grateful if you took the time to help evaluate these things.

Built With

Share this project:

Updates