Linux Con­tain­ers are Here to Stay!

The his­toric rise in the adop­tion of Linux con­tain­ers makes for in­ter­est­ing read­ing.

OpenSource For You - - Contents - The au­thor has worked with Mi­crosoft Re­search, CERN and star­tups in the AI and cy­ber se­cu­rity do­mains. An open source en­thu­si­ast, he en­joys spend­ing his time or­gan­is­ing soft­ware de­vel­op­ment work­shops for school and col­lege stu­dents. You can con­nect with h

Steve, a soft­ware en­gi­neer with a big tech firm in Sil­i­con Val­ley, has been work­ing with his team on a cool new ar­ti­fi­cial in­tel­li­gence sys­tem that the team has been de­vel­op­ing lo­cally. The team mem­bers have built it over a year, us­ing a col­lec­tion of open source tools, li­braries and soft­ware, and are now faced with the mam­moth task of de­ploy­ing it onto live servers—the stage at which the real prob­lems start kick­ing in!

The team had built all the scripts us­ing Python 2.7, be­fore re­al­is­ing that the pro­duc­tion servers had only Python 3 in­stalled. There were a num­ber of de­pen­den­cies that were in­ad­ver­tently up­graded and, as a re­sult, a lot of the code got dep­re­cated. There were var­ied se­cu­rity poli­cies, net­work topolo­gies, and dif­fer­ent types of stor­age that could not be si­mul­ta­ne­ously han­dled by the ap­pli­ca­tion. Pipe­lines broke down, re­sponses were lost and ul­ti­mately, the app crashed, splat­ter­ing er­ror mes­sages across the ter­mi­nal.

There are ob­vi­ous is­sues with de­ploy­ment, one be­ing the lack of com­pat­i­bil­ity on mul­ti­ple plat­forms and op­er­at­ing sys­tems. There are sys­tem paths that need to be set, de­pen­den­cies that need to be in­stalled, and ver­sions to be mon­i­tored for mul­ti­ple pack­ages. Of course, mod­ern-day pack­age man­agers, vir­tual en­vi­ron­ments, and au­to­mated test­ing do make things that much eas­ier. Still, get­ting the in­fra­struc­ture to pro­duc­tion-grade from a lo­cal de­vel­op­ment server is a night­mar­ish task for even the most skilled team of de­vel­op­ers. This sit­u­a­tion was ex­tremely com­mon for most de­vel­op­ers un­til the in­cep­tion of iso­lated en­vi­ron­ments within a Linux op­er­at­ing sys­tem—an idea in­tu­itively named Linux con­tain­ers.

The idea was not the first of its kind—FreeBSD jails and their ch­rooted equiv­a­lents on Linux did ex­ist since 2000. How­ever, even­tu­ally, sup­port grew around Linux con­tain­ers, ini­ti­ated by Jac­ques Géli­nas’ VServer project. The con­tain­ers we see to­day are a tech­nol­ogy that al­lows you to iso­late ap­pli­ca­tions as part of a pack­age—in­clud­ing the en­tire run­time en­vi­ron­ment that it de­pends on for ex­e­cu­tion. This makes it easy to move the ‘con­tained’ ap­pli­ca­tion from de­vel­op­ment to test­ing and pro­duc­tion while re­tain­ing full func­tion­al­ity. Linux con­tain­ers also help min­imise con­flicts that may arise be­tween de­vel­op­ment and op­er­a­tions teams by seg­re­gat­ing ar­eas of re­spon­si­bil­ity. De­vel­op­ers fo­cus on apps, and the op­er­a­tions team fo­cuses on in­fra­struc­ture. A con­tainer

im­age is es­sen­tially a stand­alone, ex­e­cutable soft­ware pack­age com­pris­ing all the tools, li­braries, set­tings and bi­na­ries re­quired to run the code on (al­most) any given op­er­at­ing en­vi­ron­ment. It helps stream­line a num­ber of tasks that would oth­er­wise lead to con­sid­er­able over­heads in terms of man-hours spent on set­ting them up.

Con­tain­ers vs vir­tu­al­i­sa­tion

Con­tain­ers pro­vide an iso­lated en­vi­ron­ment—an op­er­at­ing sys­tem­level vir­tu­al­i­sa­tion—with their own process and net­work space. This is far lighter than a vir­tual ma­chine, which pro­vides full vir­tu­al­i­sa­tion in an at­tempt to repli­cate the func­tion­al­ity of a phys­i­cal com­puter. Vir­tual ma­chines char­ac­ter­is­ti­cally use a hy­per­vi­sor for na­tive ex­e­cu­tion, in or­der to share and man­age hard­ware, al­low­ing for mul­ti­ple iso­lated en­vi­ron­ments that are shar­ing the same phys­i­cal ma­chine.

There are a num­ber of trade­offs be­tween both vir­tu­al­i­sa­tion and con­tainer­i­sa­tion but the pri­mary dif­fer­ence is as shown in Fig­ure 3.

Fea­tures of Linux con­tain­ers

Con­tain­ers pro­vide a sim­pli­fied pipe­line for ship­ping a prod­uct across test­ing and pro­duc­tion en­vi­ron­ments by elim­i­nat­ing plat­form-spe­cific re­quire­ments for an ap­pli­ca­tion.

Light­weight and re­source-friendly: They per­mit the run­ning of mul­ti­ple in­stances of ap­pli­ca­tions or op­er­at­ing sys­tems on a sin­gle host with­out much over­heads for the CPU and mem­ory, thus pre­serv­ing both rack space and power.

Rapid and easy de­ploy­ment: Con­tain­ers make the de­ploy­ment process sim­ple enough – it is just a mat­ter of down­load­ing and launch­ing mul­ti­ple in­stances of the de­sired im­age across mul­ti­ple servers. The test­ing phase be­comes swift due to the avail­abil­ity of clean sys­tem im­ages.

Process and re­source iso­la­tion: The pri­mary use-case for con­tain­ers is aptly han­dled by Linux con­tain­ers. There are mul­ti­ple ap­pli­ca­tions that run safely and se­curely on a sin­gle sys­tem—if the se­cu­rity of one is com­pro­mised, the oth­ers re­main un­af­fected.

Ser­vices: As adop­tion rates rose, ser­vices were de­vel­oped to sup­port the idea of a con­tainer. Con­trol groups (cgroups) is a ker­nel fea­ture that al­lows the CPU to limit re­sources utilised by a process. An ini­tial­i­sa­tion sys­tem (sys­temd) is used in set­ting up and man­ag­ing these pro­cesses within this iso­lated en­vi­ron­ment. An­other key fea­ture in­cluded user name spa­ces, which al­lowed lo­cal priv­i­leges to be iso­lated from global ones with­out much mod­i­fi­ca­tion of the en­vi­ron­ment.

Con­tainer man­age­ment: LXD pro­vides a sim­ple, ef­fi­cient means of man­ag­ing mul­ti­ple con­tain­ers us­ing a sim­ple REST in­ter­face. It can han­dle a large num­ber of im­ages, in­clud­ing pre-made im­ages avail­able for a va­ri­ety of Linux distri­bu­tions.

Ap­pli­ca­tions of Linux con­tain­ers

Con­tain­ers are be­ing used by thou­sands of com­pa­nies in or­der to stream­line their DevOps work­flows and to sim­plify the ship­ping pipe­line from de­vel­op­ment to pro­duc­tion en­vi­ron­ments. In 2015, the Open Con­tainer Ini­tia­tive (OCI) was launched within the Linux Foun­da­tion “…for the ex­press pur­pose of cre­at­ing open in­dus­try stan­dards around con­tainer for­mats and run­time.”

Over the years, the Red Hat Foun­da­tion has been in­stru­men­tal in pro­mot­ing as well as sup­port­ing the growth and us­age of con­tain­ers among other open source tech­nolo­gies.

The in­cep­tion and me­te­oric growth of Docker into a multi-bil­lion dol­lar busi­ness is in­dica­tive of the enor­mous po­ten­tial this tech­nol­ogy presents for busi­nesses world­wide.

Users of con­tain­ers in pro­duc­tion in­clude thou­sands of es­tab­lished busi­nesses, rang­ing from Google and Face­book, to Mi­crosoft, Ama­zon and the smaller ones seek­ing to es­tab­lish a foothold in the mar­ket.

Say what you will … con­tain­ers are here to stay!

Fig­ure 1: LXC: The Linux con­tainer

Fig­ure 2: From de­vel­op­ment to pro­duc­tion: The war­rior’s path (cour­tesy: com­mit­

Fig­ure 4: Orches­tra­tion of Linux con­tain­ers us­ing LXD (cour­tesy:

Fig­ure 3: Vir­tu­al­i­sa­tion ver­sus con­tain­ers (cour­tesy: Elas­ticHosts)

Fig­ure 5: Docker con­tain­ers (cour­tesy:

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.