Server Management

22  Download (0)

Full text

(1)

Server Management

Yunchih Chen

NTUCSIE WSLAB

(2)

Outline

● Some recap

● From workstation to server

● From one server to several

● Puppet

(3)

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?

(4)

● 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

(5)

● 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 ( ̄3 ̄) )

● LTS

● Stricter CPU, memory requirement (if run as tenant inside a data center)

● Stricter power requirement (critical for data center)

From workstation to server

(6)

Common Linux distro for server

(7)

Long Term Support (LTS)

(8)

Server on other OSs ...

● FreeBSD

used by

Yahoo, Netflix, WhatsApp, etc

● Microsoft Windows Server

used by

Stack Exchange

1

,

and many others

1: Great article about their data center in New York:

http://blog.serverfault.com/2015/03/05/how-we-upgrade-a-live-data-center/

(9)

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}

(10)

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?

(11)

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

(12)

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_history

(13)

Error-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

(14)

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?

(15)

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!

(16)

Puppet declarative

(17)

Puppet programmable

(18)

Puppet data & logic seperation

(19)

Puppet terminology

● Puppet Master:

1. Centralized server

2. Store & compile configuration

● Puppet Agent:

1. Collect system info

2. Request “catalog” from Puppet Master

(20)

Puppet workflow

Image from: http://www.slideshare.net/PuppetLabs/11-ways-to-hack-puppet-for-fun-and-productivity-luke-kanies-velocity-2012

(21)

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

(22)

That’s it ….

More about Puppet next week

Figure

Updating...

References

Related subjects :