More:

https://www.flickr.com/photos/drymek/sets/72157648523249544/

More:

https://www.flickr.com/photos/drymek/sets/72157650419919319/

Legal notice:

You can use the images for any purpose. You can modify and use for commercial. You should link to this post and/or information about the author (@drymek) (but you don’t have to).

Krótki spoiler:

Wszystko zaczęło się od prezentacji Mariusza Gila. Zwrócił moją uwagę na HHVM. Co prawda nie mogę go używać, bo Doctrine nie współpracuje, ale zawsze warto wiedzieć, że ktoś ma lepiej.

Następnie kilka osób zostało uznanych za zaginionych. Spokojnie bez paniki. Tylko tymczasowo. Pani sprzątająca pokoje odnalazła wszystkie zguby.

I ostatnia kompilacja, ale tym razem zupełnie serio. Moim zdaniem najlepsza prezentacja. Prezentacja z cyklu „jak żyć”. Najtrudniejsze z możliwych, a tutaj autor pokazał pełną klasę. Zarówno zawartość, jak i przekaz na wysokim poziomie. Karol – jakbym rozdawał jakieś nagrody, to byś ode mnie dostał za tą prezentację! (Ale nie rozdaje).

No i na sam koniec odnośnik do całego streamu:

https://www.flickr.com/photos/drymek/sets/72157648816279480/

Do zobaczenia za rok!

Dzięki za spotkanie. Mam nadzieję, że Marlena mnie jeszcze kiedyś dopuści do głosu na WIT i będzie możliwość powiedzenia czegoś więcej.

Z pomocą przychodzi projekt veewee, który ma wspomóc programistów i administratorów w automatycznym budowaniu obrazów. Veewee zajmuje się procesem od tworzenia boxa  (od ściągnięcia odpowiedniego iso z sieci), aż po wyeksportowanie wirtualnej maszyny do formatu box. Aktualnie wspiera czterech providerów: VirtualBox, VMware, KVM i Parallels.

Przykład instalacji został zrobiony na hoście na którym działa Ubuntu 14.04 LTS, a moim providerem jest VirtualBox. Na początek instalacji rvm (dostarczana w systemie wersja Ruby nie jest zalecana przez autorów):

curl -sSL https://get.rvm.io | bash
source ~/.rvm/scripts/rvm
rvm install 1.9.2

A następnie instalacja (czy kod) veewee:

git clone https://github.com/jedi4ever/veewee.git
cd veewee
rvm use 1.9.2@veewee --create
gem install bundler
bundle install

Autorzy dostarczają całkiem pokaźną listę systemów, które veewee jest w stanie utworzyć na VirtualBox (w chwili pisania postu jest to 226 systemów operacyjnych w różnych wersjach). Aby wyświetlić listę możliwości wystarczy uruchomić:

bundle exec veewee vbox templates

Mnie interesuje Ubuntu  Server w najnowszej wersji (na moment pisania postu), zatem definiuje sobię:

veewee vbox define 'ubuntu-14.04-server-amd64' 'ubuntu-14.04-server-amd64' --workdir=~/veewee

Po tej operacji zostaje utworzony katalog ~/veewee/definitions/ubuntu-14.04-server-amd64, który możemy wyedytować według własnych potrzeb. Skrypty tam zawarte to opisy:

• instalacji samego systemu (debian installer) i jego początkowej konfiguracji,
• instalacji VirtualBox Additions (dla VirtualBox) lub Parallels Tools (dla Parallels),
• konfiguracji kluczy vagranta,
• konfiguracji pakietu sudo (brak hasła),
• instalacji Ruby, puppet, chef,
• oczyszczenia obrazu z danych, które się w nim nie powinny znaleźć,
• oraz plik definition.rb opisujący proces budowania maszyny wirtualnej.

Budowanie maszyny jest narazie słabo odporne na zaniki Internetu, zwiększone obciążenie komputera (timeout dla instalacji), co sprawia, że czasem musiałem wielokrotnie uruchomić budowanie, ale uważam, że veewee jest wart uwagi mimo to.

bundle exec veewee vbox build 'ubuntu-14.04-server-amd64' --workdir=~/veewee
bundle exec veewee vbox validate 'ubuntu-14.04-server-amd64'

No i ostatecznie, po całej instalacji, utworzenie pliku box.

bundle exec veewee vbox export 'ubuntu-14.04-server-amd64'

Ostatnia komenda powoduje utworzenie pliku ~/veewee/ubuntu-14.04-server-amd64.box, który już bezpośrednio można wykorzystać w vagrancie.

vagrant box add 'ubuntu-14.04-server-amd64' '~/veewee/ubuntu-14.04-server-amd64.box'
vagrant init 'ubuntu-14.04-server-amd64'
vagrant up
vagrant ssh

ot i cała magia. Stworzenie maszyny jest stosunkowo szybkie. Gdy wyjdzie nowa wersja systemu, możemy mieć nawet nadzieje, że stare definicje zadziałają (jest tam jakaś zgodność wsteczna), a za pomocą definitions.rb i swoich własnych skryptów możemy utworzy dokładnie taką maszynę jak potrzebujemy. Taką którą będzie można wykorzystywać wielokrotnie.

Happy vagranting!

Zanim będą dostępne filmy na oficjalnym kanale PHPers, ja postanowiłem udostępnić swoją prezentację. Na początek część, w której opowiadałem o Vagrancie, a następnie sesja Live Demo. Niestety obie pozbawione komentarza, ale mam nadzieję, że PHPers wkrótce umieści wideo uzupełniające.

The new love from SymfonyCon

More:

http://goo.gl/vyB6Fh

Legal notice:

You can use the images for any purpose. You can modify and use for commercial. If you can, link to this post and/or information about the author (@drymek) (you can skip this information if you have to). You can also link to your site/presentation/whatever with photos in comments below. If you need better quality pictures (ok, maybe just in a higher resolution ;-), write to me (marcin at dryka.pl). The originals are quite large, so I will upload only those that are actually needed.

Excuse:

When shooting during talks, I tried to be invisible. Especially when it comes to flash. This is the first reason why the photos, are not as good as I’d like, but the eyes of speakers and general silence in the room seems to be more important. The second reason why the pictures are so weak: I’m not a photographer :P

Do you have any pictures?

Capifony to zbiór skryptów capistrano przeznaczonych dla aplikacji napisanych w Symfony (zarówno 1.x jak i 2). Dlaczego capifony? Już na początku nie musimy się przejmować m.in.:

• ręczną aktualizacją kodu
• czyszczeniem cache
• ściąganiem zależności composera
• zarządzaniem assetami

A w mojej konfiguracji również:

• usunięciem kontrolera deweloperskiego
• ustawianiem praw do katalogów cache i logs

Na początek należy przygotować serwer produkcyjny (docelowy). Do konfiguracji należy dodać użytkownika z poziomu którego będą wykonywane aktualizacje kodu, zainstalować acl (jeśli zamierzamy korzystać z setfacl).

production# adduser capifony
production# apt-get install git acl

Aby capifony ustawiało prawidłowo prawa dostępów do katalogów logs i cache należy dać użytkownikowi możliwość uruchamiania setfacl bez konieczności wpisywania hasła.

production# visudo

w pliku należy umieścić wpis:

capifony ALL=NOPASSWD:/bin/setfacl

Pozostają jeszcze dwie rzeczy do skonfigurowania na serwerze produkcyjnym:

Pierwsza z nich – dostęp do repozytorium gita – czyli klucze do deploymentu.

production# ssh-keygen
production# cat ~/.ssh/id_rsa.pub

A następnie wartość klucza należy skopiować do repozytorium np. dla Bitbucket:

https://bitbucket.org/drymek/codifico/admin/deploy-keys

No i ostatnia rzecz, do skonfigurowania na serwerze – serwer http.

production# vim /etc/nginx/sites-available/codifico.pl

server {
	listen   80;
	rewrite ^/app\.php/?(.*)$ /$1 permanent;

	root /usr/share/nginx/codifico.pl/current/web/;

	server_name codifico.pl;

	location / {
		index app.php;
		try_files $uri @rewriteapp;
	}

	location @rewriteapp {
    		rewrite ^(.*)$ /app.php/$1 last;
  	}

	# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000

	location ~ ^/(app|app_dev)\.php(/|$) {
		fastcgi_pass unix:/var/run/php5-fpm.sock;
		fastcgi_split_path_info ^(.+\.php)(/.*)$;
		include fastcgi_params;
		fastcgi_param  SCRIPT_FILENAME    $document_root$fastcgi_script_name;
		fastcgi_param  HTTPS              off;
  	}
	location ~ /\.ht {
		deny all;
	}
}

Tyle na serwerze produkcyjnym. Można się spokojnie wylogować :-)

Pozostaje konfiguracja na lokalnym komputerze z którego będziemy robić deployment.

Inicjalizacja capifony:

localhost# capifony .

stworzy pliki app/config/deploy.rb  i Capfile.

Aby umożliwić logowanie do serwera produkcyjnego dla użytkownika capifony kopiuje swój klucz:

localhost# ssh-copy-id -i ~/.ssh/id_rsa.pub capifony@codifico.pl

(Dla osób które nie mają ssh-copy-id na maku polecam wpis Kopiowanie kluczy SSH)

Aby capifony skonfigurowało katalogi potrzebne dla aplikacji należy uruchomić:

localhost# cap deploy:setup

Ponieważ domyślnie parameters.yml znajduje się w katalogu shared, należy go za pierwszym razem utworzyć i wypełnić treścią (ta jest oczywiście zależna od projektu).

mkdir -p /usr/share/nginx/codifico.pl/shared/app/config/
vim /usr/share/nginx/codifico.pl/shared/app/config/parameters.yml

Tyle, nareszcie można świętować patrząc jak aplikacja się wrzuca na serwer (do katalogu /var/www/codifico.pl/current, podczas gdy poprzednie wersje lądują do /var/www/codifico.pl/releases):

cap deploy

Dla ciekawskich dorzucam moją konfigurację capifony:

set :application, "codifico"
set :domain,      "capifony@#{application}.pl"
set :deploy_to,   "/var/www/#{application}.pl"
set :app_path,    "app"
set :git_domain,  "git@bitbucket.org:codifico"
set :user,        "capifony"
set :writable_dirs,     ["app/cache", "app/logs"]
set :webserver_user,    "www-data"

set :repository,  "#{git_domain}/#{application}.git"
set :scm,         :git

set :model_manager, "doctrine"
set :shared_files,  ["app/config/parameters.yml"]
set :shared_children,     [app_path + "/logs", web_path + "/uploads", "vendor"]
set :use_composer, true
set :vendors_mode, "install"
set :update_vendors, false
set :dump_assetic_assets, true
set :ssh_options, {:forward_agent => false}
default_run_options[:pty] = true

role :web,        domain                            # Your HTTP server, Apache/etc
role :app,        domain                            # This may be the same as your `Web` server
role :db,         domain, :primary => true          # This is where Symfony2 migrations will run

set  :use_sudo,       true
set  :keep_releases,  10

# Change ACL on the app/logs and app/cache directories
namespace :deploy do
  task :update_acl, :roles => :app do
    shared_dirs = [
      app_path + "/logs",
      app_path + "/cache"
    ]

    pretty_print "--> Setting up setfacl for shared directories"
    # Allow directories to be writable by webserver and this user
    run "cd #{latest_release} && sudo setfacl -R -m u:www-data:rwx -m u:#{user}:rwx #{shared_dirs.join(' ')}"
    run "cd #{latest_release} && sudo setfacl -dR -m u:www-data:rwx -m u:#{user}:rwx #{shared_dirs.join(' ')}"
    puts_ok
  end

  task :remove_dev, :roles => :app do
    pretty_print "--> Removing dev controller"
    run "cd #{latest_release} && if [ -f web/dev.php ]; then rm web/dev.php; fi;"
    puts_ok
  end
end

# Be more verbose by uncommenting the following line
# logger.level = Logger::MAX_LEVEL

• Tworzenie bazy danych z ustawieniem kodowania (jeśli administrator nie zmienił domyślnego latin1_swedish):

CREATE DATABASE <NAZWA_BAZY> CHARACTER SET utf8 COLLATE utf8_general_ci;

• Tworzenie użytkownika dla danej bazy danych:

GRANT ALL PRIVILEGES ON <NAZWA_BAZY>.* TO '<NAZWA_UZYTKOWNIKA>'@'localhost' IDENTIFIED BY '<HASLO>';

A czy Wy też utworzyliście kiedyś bazę danych nie zmieniając Collate na UTF-8? ;-)

Jeśli ktoś korzysta z homebrew instalacja jest dość prosta:

sudo brew install ssh-copy-id

Jednak w przypadku ports nie jest już tak różowo:

sudo port install openssh +ssh_copy_id

co powoduje zainstalowanie openssh, a nie zawsze tego chcemy. Dlatego najprostszą metodą wydaje się:

wget https://raw.github.com/drymek/ssh-copy-id/master/ssh-copy-id -O /usr/bin/ssh-copy-id && sudo chmod +x /usr/bin/ssh-copy-id

Ot, wszystko. Tyle wystarczy. Teraz aby skopiować klucz na serwer wystarczy wpisać:

ssh-copy-id -i ~/.ssh/id_rsa.pub username@ssh-server