84 lines
5.3 KiB
Markdown
84 lines
5.3 KiB
Markdown
# What it should become?
|
|
|
|
Utility service like puppetlabs puppet, but a bit simplified. It will consist of 2 parts - server and agent. Each agent
|
|
will be able to fetch only configs thaat intened only for it's use. On server-side there will be jsons that describing
|
|
separate hosts, host-groups and services and all of these files will be under control of some vcs like hg or git.
|
|
|
|
## When it will be ready to see and touch?
|
|
|
|
There is no due or deadline it will de ready to test or use. All depends on speed of researching abilities of lua and
|
|
other go modules. And spare time ofcorse. It is some sort of pet-project. If there is any use of this project it will
|
|
be great!
|
|
|
|
## Short story - why this project began?
|
|
|
|
The thing is that puppetlabs puppet become fat-ass monster that is relatively hard to maintain. Its development process
|
|
move relatively in fast pace newer versions are sometimes incompatible with older ones it is hotably hard to keep heap
|
|
of already working manifests, templates and configs up to date with newer versions of puppet.
|
|
|
|
Version 2.7 of puppet was relatively easy to maintain but awful to install on newer systems. Matz's Ruby Interpreter is
|
|
unable to deliver acceptable level of performance hogging cpu fast. So i have to run JRuby which using JVM which is
|
|
famous for its memory wasting. It is faster than MRI, but compiling newer JVM on older linuxes is real pain in the ass.
|
|
|
|
In ruby eco-system exist Ruby-On-Rails framework that is all-in-one solution for web apps in ruby ecosystem. But
|
|
puppetlabs puppet does not use it. So it is relatively hard to force puppet server work in proper scalable and stable
|
|
fashion. If you want to package puppet server, you have to build ruby itself, and vendor tons of modules of specific
|
|
versions and also put there puppel-server itself.
|
|
|
|
It is clear that with each new version of puppet its appetites grew in exploding manner and as of today it is became fat
|
|
beast.
|
|
|
|
So to speak, it was version 2.7 with it's own bust, that relavely well working, but it is more than 10 years old and
|
|
long ago obsoleted bu puppetlabs. It was designed to run on later versions of ruby-1.8. With some minor quirks it is
|
|
possible to make it work on ruby-1.9. But to make it work on more recent versions of ruby puppet-2.7 should be heavily
|
|
reworked. And generally puppet suffres fron performance issues because it was written entirely on ruby.
|
|
|
|
Speaking of puppet agent it is resource hog too.
|
|
|
|
Some time ago i've got an idea to puppet me home servers but in a more pleasurable manner. And I looked at what is on
|
|
"market" exist on this toppic. It was same players: puppet, chef, ansible, salstack, cfengine.
|
|
|
|
And all of these solutions have thei own weak spots. And one of the most painful is portability. For example ansible
|
|
itself claims tha it is agentless. But in reality it uses naked python on client-side, they blew somewhat-compatible
|
|
client-code on python3 stdin and it executes it. Agent is ephemeral but in order to run commands it requires real
|
|
python3 interpreter installation, so they just lie about agentlessity of puppet to sell it to sylly ones.
|
|
|
|
Nevertheless, in my opinion puppet is most suitable solution because it not only able to setup services but also
|
|
designed to support cosistent configuration and on configuration change it restores changes back. And well puppeted
|
|
servers can preserve its servers configuration. Agents regulary run and poll puppet server for configs state and compare
|
|
it with local state situation. All configs transformed to their original state and revices restarted to maintain
|
|
original configuration.
|
|
|
|
Thats why i've com to idea of making my own service same in spirit as puppet, but less complex. Its goal will be to
|
|
distribute config changes and maintain state of puppeted machines.
|
|
|
|
puppet in a nutshell, but on a diet.
|
|
|
|
## What is working mechanics?
|
|
|
|
The request made fron client to server and payload of request describes some facts abou itself like what os it running,
|
|
what its hostname, networking interfaces, addresses, package manager etc - all general info that can be required for
|
|
configuration. As respose server sends long json that describes what configs with which data should be placed on
|
|
filesystem and which services should be restarted.
|
|
|
|
## What about dashboard-а?
|
|
|
|
I am not able to make very beutiful dashboards. The idea is to cheat and make simple to use API to give the idea of
|
|
state of servers and supply some additional metrics and data. This api and be joined with monitoring system (like zabbix,
|
|
icnga, etc) to make nice dashboards and perform alerts and notifications. It is more convinient way of representing
|
|
status data in my opinion.
|
|
|
|
## Why lua was taken as scripting language?
|
|
|
|
There is more than one implementation of lua language on go. Including github.com/yuin/gopher-lua which seems to be
|
|
interesting. It gives ability to make own modules in go. At least it is possible to make own implementation of json
|
|
and http(s) modules that can be useful in lua templaing. Also it is possible to make lua module that can put variables
|
|
from go namespace to lua's.
|
|
|
|
## So, how progress on this puppet-thing implementation?
|
|
|
|
All progress in this repo.
|
|
|
|
Right now it all about r'n'd of current libraries and crutch all of this to make workint pieces of code for lua
|
|
templating engine.
|