Shulou(Shulou.com)06/01 Report--

Compared with Linux, OpenStack and other mature technology communities, the Rancher community is still in the primary stage of development. The success or failure of a technology community is not a simple code contribution, and the number of learning documents and code management work flow are also very important. How to make engineers with different needs can quickly find corresponding solutions in the community, which requires everyone to work together to promote community development and improvement. In addition to the Rancher & RancherOS,Rancher Labs development team we are familiar with, they refine a lot of practical gadgets in practice. Although these gadgets do not influence the overall development of Rancher, they bring great convenience to the team in terms of project standardization and development efficiency. The main purpose of this time is to bring you to know these gadgets.

Golang package Management tool-Trash

Project address: https://github.com/rancher/trash

At present, the mainstream programming languages such as Python, Ruby, Java and Php have designed the process of package management as smooth as a cloud. In general, developers do not need to worry about library package dependency management, upgrade, backup and team cooperation. Golang began to introduce package management design in version 1.5, adding the vendor directory to support local package management dependencies, but requiring a special setting of GO15VENDOREXPERIMENT=1, which was already the default in the 1.6 era. However, vendor does not have a unified version number management function, but only provides additional dependent paths for packages within project. So the tool Trash arises at the historic moment, the use of Trash is very simple, you only need to have a description file of the dependent package.

The description file trash.conf supports two formats, normal and YAML, in which you can directly describe the remote address and version number of the dependent library. A simple example (I use the common format here):

Then execute trash in the root directory to get the relevant version of the dependency package:

Very lightweight, very concise.

Golang compilation tool-Dapper

Project address: https://github.com/rancher/dapper

When we compile the golang execution program, because it involves collaborative development, we will encounter a problem, that is, how to ensure the consistency of the compilation environment. The best way to achieve environmental consistency is to use container technology. Dapper is the principle that various commands can be executed to generate containers in the process of Docker build mirroring. Just create the Dockerfile.dapper file in the root directory of the project, which is a file referring to the Dockerfile standard, and execute the dapper command to generate the final execution program according to the agreed rules, which unifies the compilation environment in this way.

Almost all Rancher projects are compiled based on Dapper. Open a project such as rancher-dns at random and you can see the Dockerfile.dapper file:

DAPPER_SOURCE specifies the source code path within the container

DAPPER_OUTPUT specifies the compiled output path, and the bin dist directory is automatically created under the project root.

Setting DAPPER_DOCKER_SOCKET to True is equivalent to docker run-v / var/run/docker.sock:/var/run/docker.sock.

DAPPER_ENV is equivalent to docker run-e TAG-e REPO.

It is important to note that there are currently two ways for Dapper to load source code: bind and cp,bind are the local source paths to mount directly, but if you use remote docker daemon, you have to use cp mode.

Golang Project Standardization tool go-skel

Project address: https://github.com/rancher/go-skel

The package management tools and package compilation tools are introduced, and it would be great if we could use these two tools together when creating a golang project. Go-skel provides such a convenience, let's come to demo directly.

Clone a copy of the go-skel source code, create a rancher-tour (. / skel.sh rancher-tour) project:

After execution, a standard project is created, including dapper and trash tools, and a Makefile is defined. We can simplify the operation with the make command:

For example, if we want to perform a ci operation, we can run make ci directly, run the unit test automatically, and generate the final executable in the bin directory:

The standard project has created some initialization code that integrates github.com/urfave/cli, so we can execute rancher-tour:

Micro Services Auxiliary Gadget Giddyup

Project address: https://github.com/cloudnautique/giddyup

In the process of containerization of a traditional service, we usually split it into multiple micro-services, fully demonstrating the philosophy that each container only does one thing well. Then there will be sidekick containers, data volume containers, containers dedicated to updating configuration information, and so on, that we see in Rancher.

In practical applications, we will encounter some problems, such as the startup of these micro-service containers is out of order, which may lead to connection failure between micro-services, resulting in the unavailability of the whole service; another example is how to determine that the dependent micro-service has been started normally, which may require a service port of health check. Giddyup is a powerful tool to simplify this kind of microservice inspection. What can it do:

Get connection strings from DNS or Rancher Metadata.

Determine if your container is the leader in the service.

Proxy traffic to the leader

Wait for service to have the desired scale.

Get the scale of the service

Get Managed-IP of the container (/ self/container/primary_ip)

Let's create a stack and create a service in it to experience some of the features of giddyup. The service contains two containers, the main container main and the sidekick container conf, which share the network stack:

We can start giddyup health in conf and start a http service listening on port 1620. The service path is / ping:

At this point, we can view the health status of the service health port in the containers of other services, obtain the service address through giddyup ip stringify, and view the relevant status using giddyup probe:

You can see that probe returns the information of OK, indicating that the health port of giddy/main is normal. What will happen to giddyup probe if we stop the port of giddyup health?

In addition to enabling the health port feature, you can also wait for sleep to start all containers in the service. For example, in service, I performed wait operation on main and expanded the capacity of service on UI. You can see that it took almost 3 seconds to wait for the expansion to be completed:

For more features, you can take a look at the README documentation of the giddyup project. You can also see how some projects in catalog use giddyup. Refer to: https://github.com/rancher/catalog-dockerfiles

Rancher CLI tool

Project address: https://github.com/rancher/cli

Now the way we manage Rancher includes UI and API. In order to better integrate Rancher with other tools, we have developed CLI tools, which can be very lightweight embedded in other tools. CLI will be officially released in the Rancher 1.2-pre2 version, and there is currently no plan to support the old version in terms of compatibility, so it is normal to have various problems with the old version.

Download the latest version directly in https://github.com/rancher/cli/releases for trial, and put rancher cli into PATH. Initialization is required before formal use:

Then you can perform all kinds of sharp operations, such as scale for a service, which is much simpler than using rancher-compose cli before:

For example, you can monitor rancher events in real time, and you can instantly view various tasks that are happening in Rancher, which is very useful to help troubleshoot problems and analyze the operation of the system:

Later words

There is great wisdom in gadgets, and tool culture is an important symbol of the efficient cooperation of engineer Team. High-quality tools can make project development get twice the result with half the effort, and there is also a profound concept of team culture behind it, that is, regardless of the harmonious atmosphere in which the project KPI uses individual spare time to contribute to the team. In fact, many domestic Internet companies have specially set up the position of tool development engineer, and the degree of attention to the improvement of production efficiency brought about by tools is self-evident!

Original source: Rancher Labs

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.