Completely agreed. LPI is a Linux cert, not a DevOps one.
Docker still has to run on *something* and that thing is Linux. It does
not run in a magic empty vacuum :-)
There is a common fallacy that pops up every time we develop new
wrappers that hide the grimy details and drudge from everyday work, that
somehow the underlying infrastructure magically just went away.
Another good illustration is we have python-requests so now we don't
have to deal with httplib. But python is still very much there. Trying
to argue if Linux is still relevant because we have Docker is like
trying to argue we don't need python because we have requests.
Methinks the OP might be new to this game.
Alan
On 2019/01/23 09:46, Kenneth Peiruza wrote:
Hi all,
I'm one of those who works with Docker & Cloud.
Linux matters more than ever because Linux is everywhere. Most of those
systems run on top of Linux, and debugging them requires deep Linux
knowledge.
Many Dockers suck. You need some criteria to pick the best ones in the
long term.
Then others are simply wrongly built, like Tibco's, Cloudera's or even
Oracle Dockers. Tibco abused of /tmp usage so it lead to Docker filling
/var/lib on orchestrators, whilst Cloudera and Oracle didn't got the
point: a 1GB Docker is not a container, it's a Maersk ship.
You can cut them down only if you know what's needed and what's not.
Other non-free Dockers were poorly built and only defined one exposed
port instead of two, or provide two services that should become two
Dockers instead.
Once inside that tibco docker with 2 ports, there was no net tools at
all, so we needed to check /proc to be able to see which ports were
binded as one was missing in the definition, leading Netflix Spring-boot
to fail providing it. Same for containers with multiple IPs registering
the wrong one. You need to go low-level to check them with little or no
tools.
Most Dockers are based on Debian or Alpine. You deal with apt, apk and
yum + repos.
At the end you usually have some kind of micro-system in your Dockers.
The better you're with Linux, the better for debugging and building slim
images.
Then, knowing how logs and metrics can be concentrated requires some
knowledge about syslog and or journald, and once concentrated, 98% of
people doesn't understand what load average means or how to filter logs.
Systems get auto-configured as much as possible. You achieve so with
shellscripts populating config files 90% of the time. Those scrips use
as few system commands as possible (micro-system), so you really need to
find a way to do what you need without filling that tiny system with
binaries: smaller system = faster start of your containers.
Same logic applies to create safer containers: smaller systems are safer
due to a reduced attack surface.
Then, most Dockers are webservices. Some are Java,Node/Apache
httpd/nginx/ha-proxy/mariadb.
So, yes, my Linux background is what allowed me to become a fairly good
Docker/DevOps technician, and being able to replace my IP in a config
file with a shellscript and controlling everything is ok makes my
Dockers 'better than average'.
Everyone should know at least 70% of LPIc 1 and 30% of Lpic2 to create
Dockers and to operate them.
PS: leveraging many other OpenSource technologies help you in your daily
work, just to name a few: certificates, ldap-auth, ssh & tunneling,
Kerberos, NFS and iptables are everywhere.
Regards,
Kenneth
On Jan 22, 2019 11:59 PM, Sergio Belkin <[email protected]> wrote:
Hi,
Perhaps, this sounds somewhat Off-Topic and provocative. It happens
that I'm preparing a webinar around Linux and LPIC and we are
living in a time of "kubernetes, cloud, IaaS, docker, devops, and a
bunch of techie-millenial terms". So one somewhat ends to
questioning itself, how is Linux still relevant?
Why should people to learn to master the shell, handle process,
manage partitions and tweak config and shell script files?
What do you think? What would tou say?
Has techno-devops-millenials marked the end of history and the Linux
relevance?
I will appreciate your opinions a lot.
TIA
_______________________________________________
lpi-examdev mailing list
[email protected]
https://list.lpi.org/mailman/listinfo/lpi-examdev
--
Alan McKinnon
[email protected]
_______________________________________________
lpi-examdev mailing list
[email protected]
https://list.lpi.org/mailman/listinfo/lpi-examdev
