This is the translation of my speech at T-Meetup: DevOps Life Cycle.
I believe that you have heard about SDLC (Systems development life cycle). Is it possible that the same things are applicable for the IaC?
Everyone who runs the static analyzer on a project for the first time is slightly shocked by hundreds, thousands or even tens of thousands of warnings. It may be frustrating. Is my code so terrible? Or is the analyzer lying? In any case, filtering by the severity changes the situation, not completely though. That's why we thought about how we could improve the first experience with the analyzer. Let me show you the new feature step by step...
This article continues the series of articles on load tests. Today we will analyze the testing methodology and answer the question: "How many IP cameras can be connected to a WebRTC server?"
Do you remember how just a few years ago it was a disaster to lose a camera at the end of a vacation? All memorable pictures and videos then disappeared along with the lost device. Probably, this fact prompted the great minds to invent cloud storage, so that the safety of records no longer depends on the presence of the devices on which these records are made.
We continue to review variants of load tests. In this article we will go over the testing methodology and conduct a load test that we will use to try and determine the number of users that could watch and stream at the same time, meaning the users will simultaneously publish and view the streams.
This article is a continuation of our series of write-ups about load tests for our server. We have already discussed how to compile metrics and how to use them to choose the equipment, and we also provided an overview of various load testing methods. Today we shall look at how the server handles stream mixing.
In the previous article we went over a load test whose data could be used to choose a load-appropriate server. In the course of the testing, we would publish a stream on one WCS, and we would pick up that stream several times using a second WCS. The acquired results could be used as a basis for decisions on server operability.
Some would (justly) have concerns regarding the possible biases in such a test — after all, one of our servers was used to test another one of our servers. Could it be that we were using a specially optimized code that skewed the results in our favor?
If you use Zabbix to monitor your infrastructure objects but have not previously thought about collecting and storing logs from these objects then this article is for you.
In any project, a great deal of importance is placed on the selection of server hardware and WebRTC streaming is no exception. One of the key principles of such a selection is balance – the hardware should be powerful enough to handle the streams with no drops in quality, but not too powerful so as to waste resources. So, how does one choose the right server?
Monitoring systems are a vital tool for any system administrator, because they can be used to extract specific information from services, such that:
A few weeks ago we wrote an article about Docker and WebRTC servers and talked about the intricacies of launching containers. Our readers (rightly) questioned whether Docker was a suitable tool for production, for the following reasons:
The developer or owner of a software product often faces the question of choosing a suitable location for hosting server capacity. As you know, software always meets hardware.
In the previous article we refreshed our memory of WebRTC CDN and the ways this technology helps to minimize latency for WebRTC streams. We also discussed why load balancing and autoscaling wouldn't be amiss in CDNs. Here are the main points from the article:
The modern browsers do not give users a choice between using WebRTC and not using it. And while you can playback streams using HLS or MSE, WebRTC remains the only tool for capturing camera feeds and publishing streams from a browser. The browser developers have accepted this "format" and integrated it into their products – just as they used to support the Flash Player as a plugin. The only difference is that WebRTC comes natively integrated into the browser — as code, not a plugin. If, in a few years, a new and better library for video streaming is introduced they will undoubtedly make a switch. But these days, Chrome maintains its dominance, so no contenders for WebRTC are in sight.
The vast majority of IT specialists in various fields strive to perform manually as few actions as possible. I won't be afraid of the loud words: what can be automatized, must be automatized!
Let's imagine a situation: you need to deploy a lot of servers of the same type and do it quickly. Quickly deploy, quickly undeploy. For example, to deploy test rigs for developers. When development is carried out in parallel, you may need to separate the developers, so they don't impede each other and possible errors of one of them don't block the work of the others.
There may be several ways to solve this problem:
Hi, My name is Alex and I am a DevOps engineer at Altenar. “No Windows, no problems.” - that is the answer I got by asking a guru of Ansible "How do you manage Windows?" on one of the local Ansible meetups. Although we have been running a modern stack (k8s, helm, .net core, etc) in production for about two years, that’s not how it has always been.
PVS-Studio user support often receives clients' suggestions on product improvement. We are happy to implement many of them. Recently one of the users suggested refining the automatic notification utility for developers (Blame Notifier). They asked us to make Blame Notifier extract the date/the code revision to which the analyzer issued a message using blame information from the version control system. This feature allowed us to expand the utility capabilities, which we'll discuss in this article.
"How much longer are you going to build it?" - a phrase that every developer has uttered at least once in the middle of the night. Yes, a build can be long and there is no escaping it. One does not simply redistribute the whole thing among 100+ cores, instead of some pathetic 8-12 ones. Or is it possible?
In some projects, the build script is playing the role of Cinderella. The team focuses its main effort on code development. And the build process itself could be handled by people who are far from development (for example, those responsible for operation or deployment). If the build script works somehow, then everyone prefers not to touch it, and no one ever is thinking about optimization. However, in large heterogeneous projects, the build process could be quite complex, and it is possible to approach it as an independent project.If you treat the build script as a secondary unimportant project, then the result will be an indigestible imperative script, the support of which will be rather difficult.
In this note we will take look at the criteria by which we chose the toolkit, and in the next one — how we use this toolkit. (There is also a Russian version.)
