FreeBSD Unified Configuration   Andrew Pantyukhininfofarmer@FreeBSD.org
once upon a time   a private cloud
petabytes of datadozens of gigabits of transfers   teraflops of processing
4 countries   10 cities13 data centers
11 service providers   15 support contracts       5 SLA types
~100 machines~20 hardware configurations     ~1000 hard drives
30 local networks      5 network types7 out-of-band console types
1 operating system   (potentially more)      5 boot types
1 systems engineer  1 network engineer    1 field engineer
initial tactics    owned -> clusterleased -> setup & forget
briefly considered     puppet, chef, cfenginescripted per-node management
priorities  extremely low ops load and          complexityextremely high performance and           flexibility
solutionunified configuration management        unified deployment
unified?exactly same root fs everywhereexactly same configs everywhere
/.git/usr/local/project/.git   /usr/home/*/.git
fully distributedflexible semi-auto master-master               sync no symlinking, copying (almost)
concentrated  complexitysmarter specialization role-aware configs
rolespasswd, group  aware.map
role-aware boot who am I? what are my MACs?MAC -> aware.map -> host -> roles
rc.conf - role-aware        shell script   intricate evaluation
ntpd_enable="YES"role.www() { nginx_enable="YES"                 }role.host1() { hack_enable="YES"                 }
for i in $myroles      role.$i
nginx.conf role-  compatible{ server_name www1; }{ server_name www2; }
syslog.conf role-        unaware    syslog.conf - most nodessyslog.conf.collect - log collector
rc.conf-based work-      around      role.logcol() {    syslog_flags="-c  syslog.conf.collect" }
fstab role-unaware        #empty  loader.conf, scripts
boot drive/dev/ufs/root1 - 10G/dev/ufs/root2 - 10G
boot drive/dev/gpt/swapserial - 4G /dev/ufs/serial - leftover
loader.conf     vfs.mountrootfalls back to NFS root
deploymentaware.map, configs adjustment         dhcp, etc
deploymentfind & partition a suitable drive untar recent image into root1
full upgrade untar new image into root2pivot root1<->root2 (kernel!!)
full upgrade rsync? pkgng?freebsd-update?
pkg upgrade   pkgng
continuous upgrade      git pull
edit on any box      commit, pushpowerful conflict resolution
pretty scalable
git is awful    rsync is lackingneed more smart configs
pretty simple          fool-proofsingle-view cloud-wide config
Q&A
Upcoming SlideShare
Loading in …5
×

FreeBSD Unified Configuration

1,148 views

Published on

The talk focuses on a new unified approach to deploying and managing modern versions of FreeBSD across a wide variety of technical and administrative circumstances: different countries, data centers, hardware, access policies, boot methods, networking, support contracts, machine roles, etc.

While avoiding any popular Linux-centric CM systems, such as Puppet, Chef, and CFEngine, we achieve very low complexity by leveraging rc(8), loader(8), glabel(8) and other existing instruments, such as pkgng, to their potential as necessary. The cornerstone is keeping configuration and deployment versioned and unified — same across all cases, with no duplication of common parts and very simple specification of per-role/per-case peculiarities. The approach spans everything from installation and booting to managing third-party and custom site-specific software. The method is being actively developed and applied in production environment of a popular online music service.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,148
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
11
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

FreeBSD Unified Configuration

  1. 1. FreeBSD Unified Configuration Andrew Pantyukhininfofarmer@FreeBSD.org
  2. 2. once upon a time a private cloud
  3. 3. petabytes of datadozens of gigabits of transfers teraflops of processing
  4. 4. 4 countries 10 cities13 data centers
  5. 5. 11 service providers 15 support contracts 5 SLA types
  6. 6. ~100 machines~20 hardware configurations ~1000 hard drives
  7. 7. 30 local networks 5 network types7 out-of-band console types
  8. 8. 1 operating system (potentially more) 5 boot types
  9. 9. 1 systems engineer 1 network engineer 1 field engineer
  10. 10. initial tactics owned -> clusterleased -> setup & forget
  11. 11. briefly considered puppet, chef, cfenginescripted per-node management
  12. 12. priorities extremely low ops load and complexityextremely high performance and flexibility
  13. 13. solutionunified configuration management unified deployment
  14. 14. unified?exactly same root fs everywhereexactly same configs everywhere
  15. 15. /.git/usr/local/project/.git /usr/home/*/.git
  16. 16. fully distributedflexible semi-auto master-master sync no symlinking, copying (almost)
  17. 17. concentrated complexitysmarter specialization role-aware configs
  18. 18. rolespasswd, group aware.map
  19. 19. role-aware boot who am I? what are my MACs?MAC -> aware.map -> host -> roles
  20. 20. rc.conf - role-aware shell script intricate evaluation
  21. 21. ntpd_enable="YES"role.www() { nginx_enable="YES" }role.host1() { hack_enable="YES" }
  22. 22. for i in $myroles role.$i
  23. 23. nginx.conf role- compatible{ server_name www1; }{ server_name www2; }
  24. 24. syslog.conf role- unaware syslog.conf - most nodessyslog.conf.collect - log collector
  25. 25. rc.conf-based work- around role.logcol() { syslog_flags="-c syslog.conf.collect" }
  26. 26. fstab role-unaware #empty loader.conf, scripts
  27. 27. boot drive/dev/ufs/root1 - 10G/dev/ufs/root2 - 10G
  28. 28. boot drive/dev/gpt/swapserial - 4G /dev/ufs/serial - leftover
  29. 29. loader.conf vfs.mountrootfalls back to NFS root
  30. 30. deploymentaware.map, configs adjustment dhcp, etc
  31. 31. deploymentfind & partition a suitable drive untar recent image into root1
  32. 32. full upgrade untar new image into root2pivot root1<->root2 (kernel!!)
  33. 33. full upgrade rsync? pkgng?freebsd-update?
  34. 34. pkg upgrade pkgng
  35. 35. continuous upgrade git pull
  36. 36. edit on any box commit, pushpowerful conflict resolution
  37. 37. pretty scalable
  38. 38. git is awful rsync is lackingneed more smart configs
  39. 39. pretty simple fool-proofsingle-view cloud-wide config
  40. 40. Q&A

×