eZ Americas Winter Gathering 2013
6 Feb 2013
at Courtyard Fort Myers at I-75 and Gulf Coast Town Center
Talk comments
Looks like the new version (chef 11) is very compatible with chef 10 and mostly provides some handy new bootstrap scripts (chef-apply) and adds some new tools for recipe developers.
Notes courtesy of Brandon Chambers:
Specfications
-A client has a calendar and want customers to sync with them
Using w/ eZP:
-Have users subscribe to events/calendars.
-Wanted to avoid using other formats sch as ICS
-Simple, CSS class-based, no extra HTML tags.
Issues:
-Cross browser stuff when using gCalendar
-h2vx user agents (Google Reader)
Works well with small calendars.
A novel way of providing a standard.
Comments thanks to Mark Marsiglio:
Note that Chef has just released a new version.
Managing Servers with Chef
Joe Kepley, Blend Interactive
DevOps = Development + Operations, Combine IT Operations with Development and QA functions. How can we use some of the automation and tools we develop to manage our own infrastructure?
Build a new server 1) Manually, 2) with build scripts (limited to a particular type of server and function, hard to maintain), 3) Chef - tell the computer what it should do and how it should do it
Chef and Puppet are two tools, use a DSL to define how they work.
What is Chef
Talk about the end-state desired, not the method of doing it
Idempotent - rerun script only changes, does not redo everything again
Use Recipes, Cookbooks, Attributes and Data Bags
Apache Cookbook knows what is required to configure Apache on a particular OS
Includes templates (recipes) for how things should be set up
Accepts Attributes as variables to insert into the templates
Use a Role or Environment to define an override for Attribute
Data Bags contain things like user-specific settings, keys, privileges, etc
Chef Server - stores all of the configs
Chef Client - runs on the web servers to stay in sync,
Ohai - extracts information about servers to give to Chef
Knife - command line for using chef - "create an ec2 server in this region of this size with these packages for this role with these options"
Chef Solo - Good for testing
Hosted Chef - has more options than the open source version
Git - Knife maintains cookbooks in a git repo, branches and merges as needed, but Chef Server does not talk to Git
Solr backed - query against the database for variables, such as querying the IP of a server in a script (search for a server with a role of MySQL and insert that IP here)
Development Cycle - Create cookbook, declare recipes, Chef looks for the resource to create the user (it knows to use the adduser command, for instance, and knows to edit if the user is already there)
Upload the cookbook to the Chef server
Execute on client servers
Berkshelf - dependency management, calculates dependencies for cookbooks and uploads them to the target as needed
Vagrant - automated testing environments, works with Virtualbox to give a destroyable test environment
Felipe and Aplyca have assembled a sophisticated list of techniques for handling and simplifying language issues; one of the important themes is pushing responsibility for the translations to the client, allowing asynchronous management of the translation. The next time this comes up, I'm going to ask Felipe for a consult.
These notes are courtesy of Joe Kepley. Thanks Joe!
Out of the box, eZ Provides multi-language objects, Localization
'Sprite' Translation
- |i18n and .ts files can be difficult to maintain, easy to forget to wrap strings
- Use a content object to store and translate strings in the admin area.
Soft Redirect
- AJAX call with IP database
- Remember user choice with cookie
"Separate Beds"
- Unique subtree with site access per region/language
- May need to maintain three subtrees in sync
- Created script to create locations in batch
"Chowmein" - Show Main
- define a main translation, and use main language checked to show content across multiple languages
Dictionary Approach
- Adding a new item means you have to maintain the translation forever
- XML blocks contain base values with default values
- These are embedded in the text of other articles
- May create some problems with visibility - lots of internal relationships
eZ DFS - in a cluster set-up, the DFS holds shared file assets, including cache
and images. It can be the bottleneck when supporting heavy traffic.
Rasmussen Reports: Pageview data: 2.6M page views before election day, less on
election day, and very quiet after. This loading, while quite heavy, was
actually very easily supported and the current platform and configuration is
economical and very robust.
Get Varnish from: https://varnish-cache.org/
Varnish is a reverse proxy. Be default it serves whole pages, listening to your webserver on port 88 (for example)
while serving your actual content to the world on port 80. Be default, it handles all the GET requests, and it's
very fast.
Varnish can also do load balancing, although it's also productive to sit directly on a single webserver.
Grace mode (triggered by saint mode) automatically detects that the backend is down; Varnish will continue to work.
A great use case: static html pages, huge traffic spikes.
At Rasmussen: mix of static pages, plus members, personalized pages. Varnish is simple win for the unpersonalized pages.
Versus expanding the hardware:
- can be an issue with autoscaling, with several issues such as testing
- Varnish relieves the bottle neck of the DFS, the network within the platform, or the database
Versus CDN:
- big lag out to the CDN, support is an issue, eg with Akamai
- however it doesn't have the nice proximity effect of a CDN
- thing to do is to use Varnish on the backend because Akami is itself a big load
Optimize everywhere
- browser caching; images, other assets
- minifying, less data to serve
Varnish with ez publish
- have to set up ez publish to inform Varnish that new content is published, or content is deleted, etc
Mugo extension
- https://github.com/mugoweb
- hooks the custom static cache handler, available in 4.6 or via a patch for earlier versions
- this handles all the related changes - because: A single edit may effect a lot of pages!!
- has a regex purge for manual use, available in the admin interface
Varnish runs a ban list; these are pages that are ready to be updated in the cache
Varnish config file
- determine how long to keep pages
- VCL, a very complex interface
- this is a light look at some VCL
Setup tweaks
- Varnish won't cache pages with cookies, which is a prob with < eZ 4.4, can config it to ignore cookies or process cookies specially, GA cookies
- Varnish will respect headers from the backend,
- and will suport edge control headers;
- only want to cache 200 or 400 responses, other stuff goes through to hit the servers
- edge side includes, can include parts of the page different, these can be cached differently, or not even cached at all
- eg, set sidebar ttl to a much smaller ttl
Tools
- Varnishstat, use to tune your cache confit
- Varnishadm, review ban list, review config itself
- curl is great for view headers, and headers become a great way to view the operation
questions and notes:
- memory, use 1 to 16 G; 1 G seems to work pretty well
- how to test Varnish under load; jmeter for recording real sessions, ab, loadstorm (expensive)
hard to test because the network becomes the bottleneck
- root publisher script, from Gaetano, hammers the publish process
- what's better? on its own server? versus other server?
can do either, network bottleneck; failover considerations;
note that multiple instances fo Varnish doubles the cache misses
- check out the "charles" proxy; http://www.charlesproxy.com/ - local desktop proxy to log headers
Great introduction to Chef
Comments courtesy of Miro Kresonja.
Note that this presentation included a lot of discussion with the partners about how they would like to see the interface evolve; this was part of Roland's intention: to engage the community in the process. One question which came up was JQuery versus YUI. See: http://share.ez.no/forums/ez-publish-5-platform/yui-vs-jquery for an amusing continuation.
eZPublish editing interface (Roland)
Process so far:
ez4 = facelift admin interface
Inline editing interface (shown on Github editorial system blender)
Last year (2012) - worked on prototype for new iface
developed in basement, so not properly scoped
Front end only for now, inline editing
New process started, because this was:
focusing on casual user, but we must have a holistic approach
ez needs a mix of admin and editorial tasks, and this focuses on just one type of user
need (mobile, touch friendly) interface
ezexceed people asked to join the project
ez ended up going their own way
task force started to redefine the whole UI, dedicated UI expert
only started late Dec 2012, first round to end in Feb
admin UI to be redone on top of the new Public API (EZPUBLISH6!)
Admin UI and editorial UI split up
Damian Pobel(sp?) working on admin
Worked on 6 basic user narratives (scenarios), from a ultra-simple user, to publisher-level people (power-editors).
Workflow a part of this.
Two kinds of workflow:
Predef workflow (strong, fixed process),
Flex workflow (or "ask people for review if you want to" before your article goes live)
What's in admin vs. editor?
Still work in progress, but will be a clearer division in new UI.
Editor = operations supporting the create/deliver/optimize paradigm
Other stuff in admin
Example: create new site probably not just a node creation. Group had differring opinions on where this goes (editor vs. admin iface).
Editorial - front end or back end?
Considered on both sides. Attempt to bring both together.
Also... there are going to be sites without the front end... mobile apps, etc, stuff used through API.
... then we launched into slides (Roland to share alongside these notes)
Some questions/answers:
No addition of attribute level security yet. (people said it was asked for by our clients)
Treating child pages (true pages vs. helper content) differently? Yes.
Former preview pane: more fixed now. No/reduced ability to modify preview/admin interface.
No inline editing for now. We expose the entire form?
Edit operation now in an overlay dialog.
We showed container object concept. (answer to treating child pages vs. helper content differently).
Search more and more prominent, relies on Solr. (up where tree used to be)
Publishing - changes to that entire process. New concept of revisions.
Editors along the workflow chain can access revisions without touching publishing.
When it's published, we can purge revisions.
State hooked to version.
Editing by Publishers/Approvers? Yes.
Using workflow for event-based actions now. In the future, hooks will take care of a lot of this?
Should be keep content states? Community says yes.
Object states - important vs. non-important (content protection), migrations, workflow
Make object states an editorial item? Some people say yes, but not clear. How do we label what they mean, with so many uses?
Jquery strongly preferred over yui by all devs present.
Theming? Starting HTML point? eZ started, or each dev for themselves?
Inconclusive results, but question not as clear in ez context.
We would prefer a strong ezDemo to base our designs on. (current eZDemo very liked by some here)
Roland: Theming yes, but on admin side. (more of a CSS editor?)
Roland: Would like to make a series of demo sites, and provide starting HTML.
To engage the community, the following to be considered:
1) blogs,
2) online meetups,
3) schedule feedback with power users,
4) prototypes shown and debated,
5) ez5 forums?
Is ez going to do something different than ezdemo? A bit of a wrong question to ask, ez always lets you do what you want.
Even now, there's a ton of templates that we never override (like h1-rendering template).
Maybe focus on picking the technology stack for now? JQuery vs. YUI.