Un­der­stand­ing Linux Con­tain­ers

LXC or Linux con­tain­ers are OS level vir­tu­al­i­sa­tions that run sev­eral iso­lated ap­pli­ca­tions on the par­ent con­trol host sys­tem. Through con­tainer­i­sa­tion, de­vel­op­ers can pack­age ap­pli­ca­tions with their de­pen­den­cies so that the apps can run on other host sys

OpenSource For You - - Contents - By: Ashish Bhagchan­dani and Ru­tul Gana­tra

Linux con­tain­ers are ap­pli­ca­tions that are iso­lated from the host sys­tem on which they are run­ning. De­vel­op­ers are al­lowed by the con­tain­ers to pack­age an ap­pli­ca­tion through the li­braries and de­pen­den­cies needed for the ap­pli­ca­tion, and ship it as one pack­age. For de­vel­op­ers and sysad­mins, the trans­fer of code from the de­vel­op­ment en­vi­ron­ments into pro­duc­tion is rapid and repli­ca­ble.

Con­tain­ers are sim­i­lar to vir­tual ma­chines. With con­tain­ers, one does not have to repli­cate a whole op­er­at­ing sys­tem. Con­tain­ers only need in­di­vid­ual com­po­nents in or­der to op­er­ate. This boosts per­for­mance and re­duces the size of the ap­pli­ca­tion.

A per­fect ex­am­ple to un­der­stand con­tain­ers

To un­der­stand con­tain­ers bet­ter, just imag­ine that you are de­vel­op­ing an ap­pli­ca­tion. You do your work on a lap­top and your en­vi­ron­ment has a spe­cific con­fig­u­ra­tion, which might be dif­fer­ent from that of other de­vel­op­ers. The ap­pli­ca­tion you’re de­vel­op­ing re­lies on that con­fig­u­ra­tion and is de­pen­dent on spe­cific files. Mean­while, your busi­ness has test and pro­duc­tion en­vi­ron­ments which are stan­dard­ised with their own con­fig­u­ra­tions and their own sets of sup­port­ing files. You want to em­u­late those en­vi­ron­ments as much as pos­si­ble lo­cally but with­out all of the over­head of recre­at­ing the server en­vi­ron­ments. So, how do you make your app work across these en­vi­ron­ments, pass qual­ity as­sur­ance and get your app de­ployed with­out mas­sive headaches, rewrit­ing or break­fix­ing? The an­swer is: con­tain­ers.

The con­tainer that holds your ap­pli­ca­tion has the nec­es­sary con­fig­u­ra­tion (and files) so that you can move it from de­vel­op­ment, to test­ing and on to pro­duc­tion seam­lessly. So a cri­sis is averted and ev­ery­one is happy!

That’s a ba­sic ex­am­ple, but there are many dif­fer­ent ways in which Linux con­tain­ers can be ap­plied to prob­lems, when so­lu­tions for ul­ti­mate porta­bil­ity, con­fig­ura­bil­ity and iso­la­tion are needed. It doesn’t mat­ter whether the in­fra­struc­ture is on­premise, on the cloud or a hy­brid of the two -- con­tain­ers are the so­lu­tion. Of course, choos­ing the right con­tainer plat­form is just as im­por­tant as the con­tain­ers them­selves.

How do I or­ches­trate con­tain­ers?

Orches­tra­tors man­age the nodes and con­tain­ers man­age the work load with the goal of main­tain­ing a sta­ble and scal­able en­vi­ron­ment. This in­cludes auto-scaling and self-

heal­ing ca­pa­bil­i­ties, e.g., tak­ing nodes off­line on dis­cov­er­ing ab­nor­mal be­hav­iour, restart­ing con­tain­ers, and the pos­si­bil­ity of set­ting re­source con­straints to max­imise your clus­ter us­age. Ku­ber­netes, Docker, Swarm, Docker EE and Red Hat OpenShift are vi­tal com­po­nents of orches­tra­tors.

Linux con­tain­ers help re­duce en­coun­ters be­tween your de­vel­op­ment and op­er­a­tions teams by sep­a­rat­ing ar­eas of re­spon­si­bil­ity. De­vel­op­ers can con­cen­trate on their apps and the op­er­a­tions team can fo­cus on the in­fra­struc­ture. Since Linux con­tain­ers are based on open source tech­nol­ogy, you get the lat­est and best ad­vances as soon as they’re avail­able. Con­tainer tech­nolo­gies, in­clud­ing CRI-O, Ku­ber­netes and Docker, help your team sim­plify, speed up and or­ches­trate ap­pli­ca­tion de­vel­op­ment and de­ploy­ment.

But isn’t this just vir­tu­al­i­sa­tion?

Yes and no. Here’s an easy way to think about the two:

Se­cu­rity of con­tain­ers

The se­cu­rity of Linux con­tain­ers is of paramount im­por­tance, es­pe­cially if you are deal­ing with sen­si­tive data like in bank­ing. Since dif­fer­ent soft­ware are in­stalled on dif­fer­ent con­tain­ers, it be­comes very im­por­tant to se­cure your con­tainer prop­erly to avoid any hack­ing or phish­ing at­tempts. Also, all the con­tain­ers share the same Linux ker­nel; so if there’s any vul­ner­a­bil­ity in the ker­nel it­self, it will af­fect all the con­tain­ers at­tached to it. This is the rea­son why some peo­ple con­sider vir­tual ma­chines far more se­cure than Linux con­tain­ers.

Al­though VMs are not to­tally se­cure due to the pres­ence of the hy­per­vi­sor, the lat­ter is still less vul­ner­a­ble due to its lim­ited func­tion­al­i­ties. A lot of progress has been made in mak­ing these con­tain­ers safe and se­cure. Docker and other man­age­ment sys­tems these days have made it manda­tory for their ad­min­is­tra­tors to mark con­tainer im­ages to avoid de­ploy­ment of un­trusted con­tain­ers.

Here are some of the ways to make your con­tain­ers more se­cure:

Up­dat­ing the ker­nel

Ac­cess con­trols Se­cu­rity sys­tem calls

Ad­van­tages and dis­ad­van­tages of us­ing con­tain­ers


Run­ning dif­fer­ent servers on one ma­chine min­imises the hard­ware re­sources used and the power con­sump­tion. Re­duces time to mar­ket for the prod­uct since less time is re­quired in de­vel­op­ment, de­ploy­ment and test­ing of ser­vices.

Con­tain­ers pro­vide great op­por­tu­ni­ties for DevOps and CI/CD.

Space oc­cu­pied by con­tainer based vir­tu­al­i­sa­tion is much less than that re­quired for vir­tual ma­chines.

Start­ing con­tain­ers re­quires only a few sec­onds; so in data cen­tres, they can be read­ily used in case of higher loads.


Se­cu­rity is the main bot­tle­neck when im­ple­ment­ing and us­ing con­tainer tech­nol­ogy.

Ef­fi­cient net­work­ing is also re­quired to con­nect con­tain­ers de­ployed in iso­lated lo­ca­tions.

Con­tainer­i­sa­tion leads to fewer op­por­tu­ni­ties with re­gard to OS in­stal­la­tion as com­pared to vir­tual ma­chines.

The most im­por­tant thing about con­tain­ers is the process of us­ing them, not the con­tain­ers them­selves. This process is heav­ily au­to­mated. No more are you re­quired to in­stall soft­ware by sit­ting in front of a con­sole and click­ing ‘Next’ ev­ery five min­utes. The process is also heav­ily in­te­grated. De­ploy­ment of soft­ware is cou­pled with the soft­ware de­vel­op­ment process it­self. This is why cloud na­tive ap­pli­ca­tions are be­ing driven by ap­pli­ca­tion de­vel­op­ers—they write the ap­pli­ca­tions to de­ploy the soft­ware into soft­ware ab­strac­tions of in­fra­struc­ture that they also wrote. When they check in code to GitHub, other code (that they wrote) no­tices and starts the process of test­ing, build­ing, pack­ag­ing and de­ploy­ment. If you want to, the en­tire process can be com­pletely au­to­mated so that new code is pushed to pro­duc­tion as a di­rect re­sult of check­ing in this new code.


[1] https://www.red­hat.com/en/top­ics/con­tain­ers/whats-al­inux-con­tainer [2] https://www.forbes.com/sites/justin­war­ren/2016/11/16/ con­tain­ers-fu­ture-not-fin­ished/#4851a2e27bcf [3] https://www.in­for­ma­tion­week.com/strate­gic-cio/it­strat­egy/con­tain­ers-ex­plained-9-essen­tials-you-needto-know/a/d-id/1318961? Ashish Bhagchan­dani is a data sci­ence en­thu­si­ast who loves to work on prob­lems re­lated to data an­a­lyt­ics. He can be con­tacted at ashishb­hagchan­[email protected] Ru­tul Gana­tra is a Web de­vel­oper and is pro­fi­cient in com­puter lan­guages like C, C++ and Java. He can be con­tacted at gana­[email protected]

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.