Server Management
Yunchih Chen
NTUCSIE WSLAB
Outline
● Some recap
● From workstation to server
● From one server to several
● Puppet
Some recap
● What is “init” in Linux?
● What does a service manager do?
● What does package manager do?
● Why is it generally a bad idea to “./configure && make && sudo make install ” in production server?
● Workstation is for developer
● New software, but not necessarily bleeding-edge
● A lot of software pre-installed
● A lot of users logged in simultaneously
From workstation to server
● server is for service ( virtualization host, web server, etc )
● Minimal set of very stable software
● Downtime = Out of business
● Only security updates ( hackers constantly poking for holes (￣３￣) )
● LTS
● Stricter CPU, memory requirement (if run as tenant inside a data center)
● Stricter power requirement (critical for data center)
From workstation to server
Common Linux distro for server
Long Term Support (LTS)
Server on other OSs ...
● FreeBSD
used by
Yahoo, Netflix, WhatsApp, etc
● Microsoft Windows Server
used by
Stack Exchange
1,
and many others1: Great article about their data center in New York:
http://blog.serverfault.com/2015/03/05/how-we-upgrade-a-live-data-center/
From one server to several
$ for s in linux{1..15}; do ssh $s “sudo apt-get upgrade”; done
$ for s in linux{1..15}; do screen -dm ssh $s “sudo apt-get upgrade”; done
$ parallel ssh {} "sudo apt-get upgrade" ::: linux{1..15}
From one server to several
for s in web{1..15}; do rsync -a ./ root@$s:/var/www && ssh root@$s
"chown -R www-data:www-data /var/www"; done
● Atomic upgrade?
● Reproducible?
● Any fallback?
● Error-prone?
● Scalibility?
Atomicity & Fallback
var
└── www
├── 2016-11-01-05:31 ├── 2016-11-02-09:20 ├── 2016-11-07-15:31
├── production -> 2016-11-07-15:31 └── testing -> 2016-11-02-09:20
D=$(date +%Y-%m-%d-%H:%M) \ for s in web{1..15}; do \
rsync -a ./ root@$s:/var/www/$D && \
ssh root@$s "chown -R www-data:www-data /var/www/$D"; done && \ for s in web{1..15}; do \
ssh root@$s “ln -sf /var/www/production /var/www/$D”; done
Reproducibility
● If something went wrong, can you reproduce the bug in other clean machine?
● How do you train new member?
This is no good:
sudo grep “for.*done” ~yunchih/.bash_historyError-prone
What’s wrong with this?
for s in web{1..15}; do rsync -a . / root@$s:/var/www; done
What about this?
var
└── www
├── .git
├── index.php ├── login.php
└── member_only.php
Scalibility
● What if you have hundreds of servers?
● What if you have web servers, database servers,
memcache servers, key-value store servers that must be
deployed simultaneously?
Puppet
● Configuration management tool
● Written in Ruby
● Master & Client architecture
● Use declarative language to configure your server!
● Abstraction over various platforms
● Text-based, thus can be version controlled!
Puppet declarative
Puppet programmable
Puppet data & logic seperation
Puppet terminology
● Puppet Master:
1. Centralized server
2. Store & compile configuration
● Puppet Agent:
1. Collect system info
2. Request “catalog” from Puppet Master
Puppet workflow
Image from: http://www.slideshare.net/PuppetLabs/11-ways-to-hack-puppet-for-fun-and-productivity-luke-kanies-velocity-2012
Puppet workflow 2
1. Agent collects system info, i.e. IP, OS name, CPU, memory, etc.
2. Agent sends request to master 3. Master verifies agent’s identity
4. Compile a catalog according to agent’s system info and send back to agent 5. Agent verifies the actual state of the system matches the desired state
according to the catalog from master.
6. Agent sends the result to master
Image from: http://www.slideshare.net/PuppetLabs/11-ways-to-hack-puppet-for-fun-and-productivity-luke-kanies-velocity-2012
