Final Destination
rated R 97 minutes New Line Cinema starring Devon Sawa, Ali Larter, Kerr Smith, Seann William Scott, Chad Donella, and Kristen Cloke written by Glen Morgan, James Wong, and Jeffrey Reddick directed by James Wong
A Review by Frankie Paiva
I'm not quite sure where to begin with this movie. First of all, I must say that this film is bad, a tepid piece of trash really defines it well. Yet I found myself somewhat drawn to the characters and their situation.  Some of the moments where the writing shines through (there are few of them) are mildly enjoyable, as are some several special touches that will reward the horror movie junkie.
Alex (Sawa, who appeared in the even worse Idle Hands) is very sacred of flying. He and a large group of classmates are heading to Paris for a week. Before takeoff he has a nightmare in which the plane blows up in midair. He awakens and screams that the plane is going to crash and gets himself, five other students, and a teacher kicked off the plane. The plane does indeed crash moments later, and there are no survivors. This is when Alex discovers his skill (so to speak). He can see or tell when people are going to die. When teens who got kicked off the plane begin mysteriously dying by strange causes, he sinks deeper and deeper into paranoia. He eventually believes that death itself is chasing after them, and there is no way to escape their fate. But who's next on death's list?
One of the things that really bothered me about this movie was the use of violence. The idea of death coming after teens instead of a masked serial killer is original, but the ways of death are way too drawn out, implausible, and gory. More than half of the blood could have been saved, and the movie would still achieve the R rating it appeared the filmmakers were looking for. Too many things just happen, and ideas about what is going on are grasped too quickly by the characters and it takes away a feeling of mystery. The question becomes not who the killer is, but how they will escape the killer. This movie also comes out at a bad time. It's release comes just after several highly publicized plane crashes. In particular, one that crashed while heading to Paris with students on board.
One usually expects shaky performances from teen movies, but these are in a whole new class. Seann William Scott (American Pie) and Kerr Smith (Jack on Dawson's Creek) have given two of the worst performances I've witnessed in a very, very long time. Ali Larter and Devon Sawa stand out as untalented actors too. Larter really shows her chops while performing such gut wrenching scenes as listening to a CD on a CD player, frantically trying to start a car, and doing her best to look bewildered. Acting God Devon Sawa really shows us raw, human emotion in such scenes as rolling down a hill, and looking through the latest issue of Penthouse. If things couldn't get any worse, then Tony Todd (of the original Candyman, apparently thrown in here for kicks) will really excite you as a mortician named Bludworth who appears in one scene, and is never quite explained. Other inside jokes include a character with the last name Hitchcock, a woman listening to a John Denver record, and popping up for no apparent reason, a poster for 1998's wickedly funny John Waters' film Pecker. It hangs content on Alex's wall in the beginnings scenes of the movie. It's about the only thing in this movie that isn't slapped with blood...or mediocrity.
D
Frankie Paiva<EMAIL_ADDRESS>http://www.homestead.com/cinemaparadise/mainpage.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Latest Release: 2.1.0 2018-08-13
Each of the containers found within the Crunchy Container Suite for PostgreSQL are described in further detail within their respective pages.
The containers and their relationships to the overall architecture are depicted below:
The following container images are provided with further information:
The crunchy-postgres container executes the Postgres database.
The container image is built using either the Crunchy Postgres release or the community version based upon a flag in the Makefile.
The crunchy-postgres RPMs are available to Crunchy customers only. The Crunchy release is meant for customers that require enterprise level support.
The PGDG community RPMs can be used as well by simply commenting out the Crunchy yum repo within the Dockerfiles and uncommenting the PGDG yum repo.
The setup.sql script is used to define startup SQL commands that are executed when the database is first created.
PG_MODE - either primary, replica or set, this value determines whether the database is set up as a primary or replica instance. In the case of set, it means the container is started within a StatefulSet in a Kubernetes cluster.
PG_PRIMARY_USER - the value to use for the user ID created as primaryuser. The primaryuser has super user privileges.
PG_PRIMARY_PASSWORD - the password for the PG_PRIMARY_USER database user
PG_USER - the value to use for the user ID created as a normal user. This user is created as part of the setup.sql script upon database creation and allows users to predefine an application user.
PG_PASSWORD - the password for the PG_USER database user that is created
PG_DATABASE - a database that is created upon database initialization
PG_ROOT_PASSWORD - the PostgreSQL user password set up upon database initialization
PG_LOCALE - if set, the locale you want to create the database with, if not set, the default locale is used
SYNC_REPLICA - if set, this value is used to specify the application_name of a replica that will be used for a synchronous replication
CHECKSUMS - if set, this value is used to enable the --data-checksums option when initdb is executed at initialization, if not set, the default is to not enable data checksums
ARCHIVE_MODE - if set to on, will enable continuous WAL archiving by setting the value within the postgresql.conf file archive_mode setting, if not set, the default is off
ARCHIVE_TIMEOUT - if set to a number (in seconds) , will specify the postgresql.conf archive_timeout setting, if not set, the default value of 60 is used.
PGAUDIT_ANALYZE - if set, will cause the container to also start the pgaudit_analyze program in the background
PG_PRIMARY_HOST - for when PG_MODE is set, specifies the primary host for setting the primary label
PG_REPLICA_HOST - for when PG_MODE is set, specifies the replica host for setting the replica label
PGDATA_PATH_OVERRIDE - if set, will cause the container to use a /pgdata path name of your choosing rather than the hostname of the container which is the default. This is useful for a primary in a deployment.
XLOGDIR - if set to true, will cause initdb to include --xlogdir=$PGWAL, this will cause a symlink to be created from /pgdata/containername/pg_wal (or pg_xlog if you’re running PG 9.5 or 9.6) to /pgwal/containername-wal
TEMP_BUFFERS - default is 8MB, set this value to override this PostgreSQL configuration setting
MAX_CONNECTIONS - default is 100, set this value to override this PostgreSQL configuration setting
SHARED_BUFFERS - default is 128MB, set this value to override this PostgreSQL configuration setting
WORK_MEM - default is 4MB, set this value to override this PostgreSQL configuration setting
MAX_WAL_SENDERS - default is 6, set this value to override this PostgreSQL configuration setting
ENABLE_SSHD- default is false, set this value to true to enable SSHD
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-postgres container:
use of OpenShift secrets
ability to restore from a database backup
use of custom pg_hba.conf and postgresql.conf files
ability to override postgresql.conf configuration parameters
ability to override the default setup.sql script
ability to set the database locale
ability to specify a synchronous replica application_name
ability to specify a recovery using PITR and WAL files
ability to enable SSHD
Adding locale support to the container is accomplished by running 'yum reinstall glibc_common' within the container, this increases the size of the container image and can be removed if you do not require specific locale support.
You can specify the PG_LOCALE env var which is passed to the initdb command when the initial data files are created, for example:
"name": "PG_LOCALE", "value": "fr_BE.UTF-8"
By default, no locale is specified when the initdb command is executed.
This container is the same as the crunchy-postgres container except that it includes the following PostgreSQL extensions:
postgis
pl/r
You can test the pl/r extension by running the following commands for example:
create extension plr; SELECT * FROM plr_environ(); SELECT load_r_typenames(); SELECT * FROM r_typenames(); SELECT plr_array_accum('{23,35}', 42); CREATE OR REPLACE FUNCTION plr_array (text, text) RETURNS text[] AS '$libdir/plr','plr_array' LANGUAGE 'c' WITH (isstrict); select plr_array('hello','world');
The crunchy-backup container executes a pg_basebackup against another database container. The backup is a full backup using the standard utility included with PostgreSQL, pg_basebackup.
Backups are stored in a mounted backup volume location, using the database host name plus -backups as a sub-directory, then followed by a unique backup directory based upon a date/timestamp. It is left to the user to perform database backup archives in this current version of the container. This backup location is referenced when performing a database restore.
The container is meant to be using NFS or a similar network file system to persist database backups.
BACKUP_LABEL - when set, will set the label of the backup, if not set the default label used is crunchy-backup
BACKUP_HOST - required, this is the database we will be doing the backup for
BACKUP_USER - required, this is the database user we will be doing the backup with
BACKUP_PASS - required, this is the database password we will be doing the backup with
BACKUP_PORT - required, this is the database port we will be doing the backup with
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The crunchy-pgdump container executes either a pg_dump or pg_dumpall against another Postgres database.
Dumps are stored in a mounted backup volume location, using the database host name plus -backups as a sub-directory, then followed by a unique backup directory based upon a date/timestamp. It is left to the user to perform database dump archives in this current version of the container.
The container is meant to be using NFS or a similar network file system to persist database dumps.
PGDUMP_DB - Database to connect to
PGDUMP_HOST - Hostname of the PostgreSQL database to connect to
PGDUMP_PASS - Password of the PostgreSQL role used by the pgdump container
PGDUMP_USER - PostgreSQL Role used by the pgdump container
PGDUMP_ALL - Run pg_dump
instead of pg_dumpall
. Default is true, set to false to use pg_dump
PGDUMP_CUSTOM_OPTS - Advanced options to pass into pg_dump
or pg_dumpall
. Default is empty
PGDUMP_FILENAME - Name of the file created by the pgdump
container. Default is dump
PGDUMP_PORT - Port of the PostgreSQL database to connect to. Default is 5432
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs Note: this mode can reveal secrets in logs.
Note: For a list of advanced options for configuring the PGDUMP_CUSTOM_OPTS
variable, see the official documentation:
Crunchy Collect container provides real time metrics about the PostgreSQL database via an API. These metrics are scrapped and stored by Crunchy Prometheus time-series database and visualized by Crunchy Grafana.
This container requires TCP access to the PostgreSQL database to run queries for collecting metrics. The PostgreSQL database to be scrapped is specified by the DATA_SOURCE_NAME environment variable.
Additionally, custom queries to collect metrics can be specified by the user. By mounting a queries.yml file to /conf on the container, additionally metrics can be specified for the API to collect. For an example of a queries.yml file, see here.
Required:
DATA_SOURCE_NAME - The URL for the PostgreSQL server’s data source name. This is required to be in the form of postgresql://.
Optional: * CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
Prometheus is a multi-dimensional time series data model with an elastic query language. It is used in collaboration with Grafana in this metrics suite. Overall, it’s reliable, manageable, and operationally simple for efficiently storing and analyzing data for large-scale environments. It scraps metrics from exporters such as Crunchy Collect.
The following port is exposed by the crunchy-prometheus container:
crunchy-prometheus:9090 - the Prometheus web user interface
The Crunchy Prometheus container must be able to reach the Crunchy Collect container to scrape metrics.
By default, Crunchy Prometheus detects which environment its running on (Docker, Kube or OCP) and applies a default configuration. If this container is running on Kube or OCP, it will use the Kubernetes API to discover pods with the label "crunchy-collect": "true". Crunchy Collect container must have this label to be discovered.
For Docker environments the Crunchy Collect hostname must be specified as an environment variable.
A user may define a custom prometheus.yml file and mount to /conf for custom configuration. For a configuration examples, see here.
Required:
COLLECT_HOST - Hostname of Crunchy Collect container. Only required in Docker environments.
Optional:
SCRAPE_INTERVAL - default is "5s", set this value to the number of seconds to scrape metrics from exporters.
SCRAPE_TIMEOUT - default is "5s", set this value to the number of seconds to timeout when scraping metrics from exporters.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
Visual dashboards are created from the collected and stored data that crunchy-collect and crunchy-prometheus provides with the crunchy-grafana container, which hosts a web-based graphing dashboard called Grafana.
Grafana is an open-source platform which can then apply the defined metrics and visualize information through various tools. It is extremely flexible with a powerful query and transformation language, producing beautiful and easily understandable graphics to analyze and monitor your data.
By default, Crunchy Grafana will register the Crunchy Prometheus datasource within Grafana and import a premade dashboard for PostgreSQL monitoring.
The following port is exposed by the crunchy-grafana container:
crunchy-grafana:3000 - the Grafana web user interface
The Crunchy Grafana container must be able to reach the Crunchy Prometheus container.
Users must specify an administrator user and password to provide basic authentication for the web frontend.
Additionally the Prometheus Host and Port are required. If Prometheus uses basic authentication, users must specify the username and password to access Prometheus via environment variables.
Users may define a custom defaults.ini file and mount to /conf for custom configuration. For a configuration examples, see here.
Required:
ADMIN_USER - specifies the administrator user to be used when logging into the web frontend.
ADMIN_PASS - specifies the administrator password to be used when logging into the web frontend.
PROM_HOST - specifies the Prometheus container hostname for auto registering the prometheus datasource.
PROM_PORT - specifies the Prometheus container port for auto registering the prometheus datasource.
Optional:
PROM_USER - specifies the Prometheus username, if one is required.
PROM_PASS - specifies the Prometheus password, if one is required.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The crunchy-pgbadger container executes the pgbadger utility. A small http server is running on the container, when a request is made to:
http://<<ip address>>:10000/api/badgergenerate
Optional:
BADGER_TARGET - only used in standalone mode to specify the name of the container, also used to find the location of the database log files in /pgdata/$BADGER_TARGET/pg_log/*.log
BADGER_CUSTOM_OPTS - no default, set this value to provide custom flags to pgbadger. For a list of optional flags, see the official pgBadger documentation.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-pgbadger container:
Generate a full report by default
Optional custom options for more advanced use cases (such as incremental
reports)
Report persistence on a volume
The crunchy-pgpool container executes the pgpool utility. Pgpool can be used to provide a smart PostgreSQL-aware proxy to a PostgreSQL cluster, both primary and replica, so that applications can only have to work with a single database connection.
Postgres replicas are read-only whereas a primary is both read and write capable.
The default pgpool examples use a Secret to hold the set of pgpool configuration files used by the examples. The Secret is mounted into the pgconf volume mount where the container will look to find configuration files. If you do not specify your own configuration files via a Secret then you can specify environment variables to the container that it will attempt to use to configure pgpool, this is not recommended however for a real pgpool deployment.
PG_USERNAME - user to connect to PostgreSQL
PG_PASSWORD - user password to connect to PostgreSQL
PG_PRIMARY_SERVICE_NAME - database host to connect to for the primary node
PG_REPLICA_SERVICE_NAME - database host to connect to for the replica node
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-pgpool container:
basic invocation of pgpool
crunchy-watch runs as a pod unto itself typically. The watch container essentially does a health check on a primary database container and performs a failover sequence if the primary is not reached.
The watch container has access to a service account that is used inside the container to issue commands to OpenShift.
In Kube 1.5, if a policy file is being used for securing down the Kube cluster, you could possibly need to add a policy to allow the pg-watcher service account access to the Kube API as mentioned here: https://kubernetes.io/docs/admin/authorization/abac/#a-quick-note-on-service-accounts
In Kube 1.6, an equivalent RBAC policy is also possibly required depending on your authorization/authentication configuration. See this link for details on the new RBAC policy mechanism: https://kubernetes.io/docs/admin/authorization/rbac/
For example, you can grant cluster-admin permissions on the pg-watcher service account, in the my-namespace namespace as follows:
kubectl create clusterrolebinding pgwatcher-view-binding --clusterrole=cluster-admin --serviceaccount=my-namespace:pg-watcher
A less wide open policy would be applied like this on Kube 1.6 rbac:
kubectl create rolebinding my-sa-binding --clusterrole=admin --serviceaccount=demo:pg-watcher --namespace=demo
|
Note
|
this kubectl command is only available in Kube 1.6, for prior Kube release such as 1.5 and the alpha RBAC, you will need to specify the role binding in a JSON/YAML file instead of using this command syntax above. |
You then reference the SA within the POD spec.
The oc/docker/kubectl commands are included into the container from the host when the container image is built. These commands are used by the watch logic to interact with the replica containers.
Starting with release 1.7.1 crunchy-watch source code is relocated to https://github.com/crunchydata/crunchy-watch
CRUNCHY_WATCH_HEALTHCHECK_INTERVAL - the time to sleep in seconds between checking on the primary
CRUNCHY_WATCH_FAILOVER_WAIT - the time to sleep in seconds between triggering the failover and updating its label (default is 40 secs)
PG_CONTAINER_NAME - if set, the name of the container to refer to when doing an exec, this is required if you have more than 1 container in your database pod
CRUNCHY_WATCH_PRIMARY - the primary service name
CRUNCHY_WATCH_REPLICA - the replica service name
PG_PRIMARY_PORT - database port to use when checking the database
CRUNCHY_WATCH_USERNAME - database user account to use when checking the database using pg_isready utility
CRUNCHY_WATCH_DATABASE - database to use when checking the database using pg_isready
REPLICA_TO_TRIGGER_LABEL - the pod name of a replica that you want to choose as the new primary in a failover; this will override the normal replica selection
CRUNCHY_WATCH_PRE_HOOK - path to an executable file to run before failover is processed.
CRUNCHY_WATCH_POST_HOOK - path to an executable file to run after failover is processed.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The watch container will watch the primary, if the primary dies, then the watcher will:
create the trigger file on the replica that will become the new primary
change the labels on the replica to be those of the primary
start watching the new primary in case that falls over next
look for replicas that have the metadata label value of replicatype=trigger to prefer the failover to. If found, it will use the first replica with that label; if not found, it will use the first replica it finds.
Example of looking for the failover replica:
oc get pod -l name=pg-replica-rc-dc NAME READY STATUS RESTARTS AGE pg-replica-rc-dc 1/1 Running 2 16m pg-replica-rc-dc-1-96qs8 1/1 Running 1 16m oc get pod -l replicatype=trigger NAME READY STATUS RESTARTS AGE pg-replica-rc-dc 1/1 Running 2 16m
The crunchy-vacuum container allows you to perform a SQL VACUUM job against a PostgreSQL database container. You specify a database to vacuum using various environment variables which are listed below. It is possible to run different vacuum operations either manually or automatically through scheduling.
The crunchy-vacuum image is executed, passed in the Postgres connection parameters to the single-primary PostgreSQL container. The type of vacuum performed is dictated by the environment variables passed into the job.
The complete set of environment variables read by the crunchy-vacuum job include:
VAC_FULL - when set to true adds the FULL parameter to the VACUUM command
VAC_TABLE - when set, allows you to specify a single table to vacuum, when not specified, the entire database tables are vacuumed
JOB_HOST - required variable is the postgres host we connect to
PG_USER - required variable is the postgres user we connect with
PG_DATABASE - required variable is the postgres database we connect to
PG_PASSWORD - required variable is the postgres user password we connect with
PG_PORT - allows you to override the default value of 5432
VAC_ANALYZE - when set to true adds the ANALYZE parameter to the VACUUM command
VAC_VERBOSE - when set to true adds the VERBOSE parameter to the VACUUM command
VAC_FREEZE - when set to true adds the FREEZE parameter to the VACUUM command
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The crunchy-dba container implements a cron scheduler. The purpose of the crunchy-dba container is to offer a way to perform simple DBA tasks that occur on some form of schedule such as backup jobs or running a vacuum on a single Postgres database container.
You can either run the crunchy-dba container as a single pod or include the container within a database pod.
The crunchy-dba container makes use of a Service Account to perform the startup of scheduled jobs. The Kube Job type is used to execute the scheduled jobs with a Restart policy of Never.
The following environment variables control the actions of crunchy-dba:
OSE_PROJECT - required, the OSE project name to log into
JOB_HOST - required, the PostgreSQL container name the action will be taken against
VAC_SCHEDULE - if set, this will start a vacuum job container. The setting value must be a valid cron expression as described below.
BACKUP_SCHEDULE - if set, this will start a backup job container. The setting value must be a valid cron expression as described below.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
For a vacuum job, you are required to supply the following environment variables:
JOB_HOST
PG_USER
PG_PASSWORD
PG_DATABASE - defaults to postgres when not specified
PG_PORT - defaults to 5432 when not specified
VAC_ANALYZE(optional) - defaults to true when not specified
VAC_FULL(optional) - defaults to true when not specified
VAC_VERBOSE(optional) - defaults to true when not specified
VAC_FREEZE(optional) - defaults to false when not specified
VAC_TABLE(optional) - defaults to all tables when not specified, or you can set this value to indicate a single table to vacuum
For a backup job, you are required to supply the following environment variables:
JOB_HOST
PG_USER - database user used to perform the backup
PG_PASSWORD - database user password used to perform the backup
PG_PORT - port value used when connecting for a backup to the database
BACKUP_PV_CAPACITY - a value like 1Gi is used to define the PV storage capacity
BACKUP_PV_PATH - the storage path used to build the PV
BACKUP_PV_HOST - the storage host used to build the PV
BACKUP_PVC_STORAGE - a value like 75M means to allow 75 megabytes for the PVC used in performing the backup
A cron expression represents a set of times, using 6 space-separated fields.
| Field name | Mandatory? | Allowed values | Allowed special characters |
|---|---|---|---|
Seconds |
Yes |
0-59 |
* / , - |
Minutes |
Yes |
0-59 |
* / , - |
Hours |
Yes |
0-23 |
* / , - |
Day of month |
Yes |
1-31 |
* / , - ? |
Month |
Yes |
1-12 or JAN-DEC |
* / , - |
Day of week |
Yes |
0-6 or SUN-SAT |
* / , - ? |
|
Note
|
Month and Day-of-week field values are case insensitive. SUN'', Sun'',
and ``sun'' are equally accepted.
|
The asterisk indicates that the cron expression will match for all values of the field; e.g., using an asterisk in the 5th field (month) would indicate every month.
Slashes are used to describe increments of ranges. For example 3-59/15 in
the 1st field (minutes) would indicate the 3rd minute of the hour and every
15 minutes thereafter. The form *\/…'' is equivalent to the form
first-last/…'', that is, an increment over the largest possible range of
the field. The form N/…'' is accepted as meaning
N-MAX/…'', that is,
starting at N, use the increment until the end of that specific range.
It does not wrap around.
Commas are used to separate items of a list. For example, using ``MON,WED,FRI'' in the 5th field (day of week) would mean Mondays, Wednesdays and Fridays.
Hyphens are used to define ranges. For example, 9-17 would indicate every hour between 9am and 5pm inclusive.
Question mark may be used instead of '*' for leaving either day-of-month or day-of-week blank.
You may use one of several pre-defined schedules in place of a cron expression.
| Entry | Description | Equivalent To |
|---|---|---|
@yearly (or @annually) |
Run once a year, midnight, Jan. 1st |
0 0 0 1 1 * |
@monthly |
Run once a month, midnight, first of month |
0 0 0 1 * * |
@weekly |
Run once a week, midnight on Sunday |
0 0 0 * * 0 |
@daily (or @midnight) |
Run once a day, midnight |
0 0 0 * * * |
@hourly |
Run once an hour, beginning of hour |
0 0 * * * * |
You may also schedule a job to execute at fixed intervals. This is supported by formatting the cron spec like this:
@every <duration>
where ``duration'' is a string accepted by time.ParseDuration (http://golang.org/pkg/time/#ParseDuration).
For example, ``@every 1h30m10s'' would indicate a schedule that activates every 1 hour, 30 minutes, 10 seconds.
|
Note
|
The interval does not take the job runtime into account. For example, if a job takes 3 minutes to run, and it is scheduled to run every 5 minutes, it will have only 2 minutes of idle time between each run. |
All interpretation and scheduling is done in the machines local time zone (as provided by the Go time package (http://www.golang.org/pkg/time). Be aware that jobs scheduled during daylight-savings leap-ahead transitions will not be run!
Crunchy pgBouncer is a lightweight connection pooler for PostgreSQL databases.
PGBOUNCER_PASSWORD - the password of the pgbouncer role in PostgreSQL. Must be also set on the primary database.
PG_SERVICE - the hostname of the database service
DEFAULT_POOL_SIZE - default 20, how many server connections to allow per user/database pair.
MAX_CLIENT_CONN - default 100, maximum number of client connections allowed.
MAX_DB_CONNECTIONS - default unlimited, do not allow more than this many connections per-database.
MIN_POOL_SIZE - default 0 (disabled), adds more server connections to pool if below this number.
POOL_MODE - default session
, specifies when a server connection can be reused by other clients.
Possible values: session
, transaction
and statement
.
RESERVE_POOL_SIZE - default 0 (disabled), how many additional connections to allow to a pool.
RESERVE_POOL_TIMEOUT - default 5, if a client has not been serviced in this many seconds, pgbouncer enables use of additional connections from reserve pool. 0 disables.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-pgbouncer container:
Crunchy pgBouncer uses auth_query
to authenticate users. This requires only the pgbouncer
username and password in users.txt
. Automatically generated from environment variables.
Mount a custom users.txt
and pgbouncer.ini
configurations for advanced usage.
Tune pooling parameters via environment variables.
Connect to the administration database in pgBouncer to view statistics of the target databases.
OpenShift: If custom configurations aren’t being mounted, an emptydir volume is required
to be mounted at /pgconf
.
Superusers
cannot connect through the connection pooler.
The crunchy-backrest-restore container executes the pgbackrest utility, allowing FULL and DELTA restore capability. See the pgbackrest guide for more details. https://github.com/pgbackrest/pgbackrest
Required:
* STANZA - desired stanza to restore from. For most cases this should be set to db
.
Optional:
* DELTA - when set to true, this will configure pgBackRest to do a delta restore. Delta
restores do not require pgdata
directoy to be empty. This will only pull in differences
between pgdata and the backup.
* BACKREST_CUSTOM_OPTS - pass in custom parameters to pgBackRest for advanced use cases (such as
point in time recovery).
* CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs.
Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-backrest-restore container:
mount pgbackrest.conf config file via /pgconf volume
mount the /backrestrepo for access to pgbackrest archives
for configuration, has to have pgbackrest.conf files mounted in /pgconf
must have valid pgbackrest archive directory mounted in /backrestrepo
The crunchy-ppgadmin4 container executes the pgadmin4 web application.
The pgadmin4 project is found at the following location: https://www.pgadmin.org/
pgadmin4 provides a web user interface to PostgreSQL databases. A sample screenshot is below:
PGADMIN_SETUP_EMAIL - required, set this value to the email address used for pgAdmin4 login.
PGADMIN_SETUP_PASSWORD - required, set this value to a password used for pgAdmin4 login. This should be a strong password.
SERVER_PORT - default is 5050, set this value to a change the port pgAdmin4 listens on.
ENABLE_TLS - default is false, set this value to true to enable HTTPS on the pgAdmin4 container. This requires a server.key and server.crt to be mounted on the /certs directory.
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-pgadmin4 container:
expose port (5050 by default) which is the web server port
mount a certificate and key to the /certs directory and set ENABLE_TLS to true to activate HTTPS mode.
Set username and password for login via environment variables.
An emptyDir, with write access, must be mounted to the /run/httpd directory in OpenShift.
The restore image provides a means of performing a restore of a dump from pg_dump or pg_dumpall via psql or pg_restore to a Postgres container database.
As the input files for crunchy-pgrestore, files generated by crunchy-pgdump are retrieved in a mounted backup volume location, using the database host name plus -backups as a sub-directory, then followed by a unique backup directory based upon a date/timestamp. It is left to the user to restore database dump archives in this current version of the container.
The container is meant to be using NFS or a similar network file system to retrieve database dumps to be restored via psql or pg_restore.
PGRESTORE_DB - Database to connect to
PGRESTORE_HOST - Hostname of the PostgreSQL database to connect to
PGRESTORE_PASS - Password of the PostgreSQL role used by the pgdump container
PGRESTORE_USER - PostgreSQL Role used by the pgdump container
PGDUMP_BACKUP_HOST - Hostname of the PostgreSQL server that was backed up by pgdump
container. Used when restoring a backup to a new host.
PGRESTORE_BACKUP_TIMESTAMP - Timestamp of the backup to restore from. Default is empty (restores from latest backup)
PGRESTORE_CUSTOM_OPTS - Advanced options to pass into pg_restore
. Default is empty
PGRESTORE_PORT - Port of the PostgreSQL database to connect to. Default is 5432
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs Note: this mode can reveal secrets in logs.
Note: For a list of advanced options for configuring the PGRESTORE_CUSTOM_OPTS
variable, see the official documentation:
The crunchy-upgrade container contains both the 9.5/9.6 and 9.6/10 Postgres packages in order to perform a pg_upgrade from 9.5 to 9.6 or 9.6 to 10 versions.
OLD_DATABASE_NAME - required, refers to the database (pod) name that we want to convert
NEW_DATABASE_NAME - required, refers to the database (pod) name that we give to the upgraded database
OLD_VERSION - required, the Postgres version of the old database
NEW_VERSION - required, the Postgres version of the new database
PG_LOCALE - if set, the locale you want to create the database with, if not set, the default locale is used
CHECKSUMS - if set, this value is used to enable the --data-checksums option when initdb is executed at initialization, if not set, the default is to not enable data checksums
XLOGDIR - if set, initdb will use the specified directory for WAL
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
The following features are supported by the crunchy-upgrade container:
supports only a pg_upgrade of the Postgres database
doesn’t alter the old database files
creates the new database directory
does NOT support a postgis upgrade currently
all environment variables are required
supports upgrades from 9.5/9.6 to 10
The crunchy-sim container is a simple traffic simulator for PostgreSQL.
PGSIM_HOST - required, the PostgreSQL host address
PGSIM_PORT - required, the PostgreSQL host port
PGSIM_USERNAME - required, the PostgreSQL username
PGSIM_PASSWORD - required, the PostgreSQL password
PGSIM_DATABASE - required, the database to connect
PGSIM_INTERVAL - required, The units of the simulation interval
PGSIM_MININTERVAL - required, the minimum interval value
PGSIM_MAXINTERVAL - requited, the maximum interval value
CRUNCHY_DEBUG - default is false, set this value to true to debugging in logs. Note: this mode can reveal secrets in logs.
Valid values for PGSIM_INTERVAL are as follows:
millisecond
second
minute
Creates a single connection to PostgreSQL and will execute queries over a specified interval range.
Queries are specified through a simple YAML file. Each query is a name-value
pair and can span multiple lines by utilizing scalar notation (|'' or
>'') as
defined by the YAML spec.
Queries are randomly chosen for execution.
Only one connection is created for all queries. >>>>>>> aae224745f5caf481c142b4ccbf3332ab4f45f8e


|
|||||||||||
| PREV NEXT | FRAMES NO FRAMES |
| Packages that use InvocationConstraint | |
| net.jini.core.constraint | Defines constraints and collections of constraints that can be used to control method invocation, and an interface that proxies implement to allow clients to specify constraints for remote method calls. |
| net.jini.jeri.ssl | Provides implementations of Endpoint and ServerEndpoint that use TLS/SSL and HTTPS (HTTP over
TLS/SSL) to support invocation constraints. |
| Uses of InvocationConstraint in net.jini.core.constraint |
| Subinterfaces of InvocationConstraint in net.jini.core.constraint | |
interface |
RelativeTimeConstraint
Implemented by constraints that are expressed in terms of relative time, to support conversion to absolute time constraints. |
| Classes in net.jini.core.constraint that implement InvocationConstraint | |
class |
ClientAuthentication
Represents a constraint on authentication of the client to the server. |
class |
ClientMaxPrincipal
Represents a constraint on the client, such that if the client authenticates itself, then it may only authenticate itself as one or more of the specified principals. |
class |
ClientMaxPrincipalType
Represents a constraint on the client, such that if the client authenticates itself, then it may only authenticate itself as principals that are instances of one or more of the specified classes. |
class |
ClientMinPrincipal
Represents a constraint on the client, such that if the client authenticates itself, then it must authenticate itself as at least all of the specified principals. |
class |
ClientMinPrincipalType
Represents a constraint on the client, such that if the client authenticates itself, then it must authenticate itself such that, for each specified class, at least one authenticated principal is an instance of that class. |
class |
Confidentiality
Represents a constraint on the confidentiality of message contents. |
class |
ConnectionAbsoluteTime
Represents a constraint on the absolute time by which a network connection must be established. |
class |
ConnectionRelativeTime
Represents a constraint on the maximum amount of time to wait for a network connection to be established. |
class |
ConstraintAlternatives
Combines two or more constraint alternatives into a single overall constraint. |
class |
Delegation
Represents a constraint on delegation from the client to the server. |
class |
DelegationAbsoluteTime
Represents a constraint on delegation, such that if delegation is permitted, it be permitted only for a range of absolute times. |
class |
DelegationRelativeTime
Represents a constraint on delegation, such that if delegation is permitted, it be permitted only for a range of time measured relative to the start of the remote call. |
class |
Integrity
Represents a constraint on the integrity of message contents, covering not only data transmitted in band as part of the remote call itself, but also out-of-band downloaded code. |
class |
ServerAuthentication
Represents a constraint on authentication of the server to the client. |
class |
ServerMinPrincipal
Represents a constraint on the server, such that if the server authenticates itself, then it must authenticate itself as at least all of the specified principals. |
| Methods in net.jini.core.constraint that return InvocationConstraint | |
InvocationConstraint |
DelegationRelativeTime.makeAbsolute(long baseTime)
Returns a DelegationAbsoluteTime instance with times obtained
by adding the specified base time argument to the duration values
from this instance. |
static InvocationConstraint |
ConstraintAlternatives.create(InvocationConstraint[] constraints)
Returns a constraint representing the specified alternative constraints, with duplicate constraints removed. |
static InvocationConstraint |
ConstraintAlternatives.create(Collection c)
Returns a constraint representing the specified alternative constraints, with duplicate constraints removed. |
InvocationConstraint |
ConstraintAlternatives.makeAbsolute(long baseTime)
Returns a constraint equal to the result of taking the constraints in this instance, replacing each constraint that is an instance of RelativeTimeConstraint with the result of invoking that
constraint's makeAbsolute method with the specified base
time, and invoking the create method of this class with
the revised collection of constraints. |
InvocationConstraint |
RelativeTimeConstraint.makeAbsolute(long baseTime)
Converts this constraint to absolute time. |
InvocationConstraint |
ConnectionRelativeTime.makeAbsolute(long baseTime)
Returns a ConnectionAbsoluteTime instance with time obtained
by adding the specified base time argument to the duration value
from this instance. |
| Methods in net.jini.core.constraint with parameters of type InvocationConstraint | |
static InvocationConstraint |
ConstraintAlternatives.create(InvocationConstraint[] constraints)
Returns a constraint representing the specified alternative constraints, with duplicate constraints removed. |
| Constructors in net.jini.core.constraint with parameters of type InvocationConstraint | |
ConstraintAlternatives(InvocationConstraint[] constraints)
Creates an instance containing the specified alternative constraints, with duplicate constraints removed. |
|
InvocationConstraints(InvocationConstraint req,
InvocationConstraint pref)
Creates an instance that has the first constraint, req ,
added as a requirement if it is a non-null value, and has
the second constraint, pref , added as a preference if it
is a non-null value and is not a duplicate of the
requirement. |
|
InvocationConstraints(InvocationConstraint[] reqs,
InvocationConstraint[] prefs)
Creates an instance that has all of the constraints from the first array, reqs , added as requirements if the array is a
non-null value, and has all of the constraints from
the second array, prefs , added as preferences if the
array is a non-null value. |
| Uses of InvocationConstraint in net.jini.jeri.ssl |
| Classes in net.jini.jeri.ssl that implement InvocationConstraint | |
class |
ConfidentialityStrength
Represents a constraint that, if confidentiality of message contents is ensured, the specified strength of confidentiality be used. |
|
|||||||||||
| PREV NEXT | FRAMES NO FRAMES |


Number of broadcasts per channel by year.
Date
BBC Four
BBC News 24
BBC One
BBC Three
BBC Two
CBBC
CBeebies


I’m working on a personal branding exercise and would value your candid input.
Please answer the questions below as best you can.
Note that the software auto-saves with each keystroke.
1. Core values
What do you think my core values are?
2. Key strengths and weaknesses
What are my key skills, strengths and expertise?
What are the weaknesses that may hold me back?
3. Unique value proposition
What is my unique expertise or value that differentiates me?
4. Personality/image attributes
How do I come across to others?
What are the key adjectives that describe my personality?
Describe my look and style.
5. Leadership attributes
What kind of a leader am I?
6. Relationship attributes
What is it like to engage with me—professionally and socially?
7. What is a living or inanimate thing that best represents my brand?
Please explain. Examples:
A trusted Saint Bernard dog who always come to the rescue
A Mini Cooper car that is efficient, fun to drive and has a quirky sense of style


Spinnaker cannot create a load balancer for Cloud Run. A Spinnaker load balancer maps to a Cloud Run service which along with a Revision are created from Create Server Group page using a
yaml file
If a service does not exist when a Revision is deployed, it will be created. It will then be editable as a load balancer within Spinnaker.


Preparation time
less than 30 mins
Cooking time
30 mins to 1 hour
Serves
Serves 6
Take on the takeaway with Anjum Anand's recipe for the ultimate lamb rogan josh.
Heat the oil in a large pan over a medium heat. Add the black peppercorns, black and green cardamom pods, cloves, cinnamon and mace and fry for 1-2 minutes, or until the spices are sizzling and fragrant.
Add the chopped onion and fry for 8-10 minutes, stirring regularly, until golden-brown.
Add the lamb pieces and fry for 3-4 minutes, stirring continually, until golden-brown all over.
Meanwhile, in a food processor, blend the garlic cloves and ginger with one tablespoon of water to a fine paste.
Add the garlic and ginger paste to the lamb mixture, stir well to combine, then reduce the heat and continue to cook for 3-4 minutes, stirring regularly.
Stir in the powdered coriander, cumin, red chilli powder, fennel seeds, garam masala, salt, tomato pulp and yoghurt, cover the pan with a lid, then reduce the heat to a low heat and simmer for 10-12 minutes, or until the sauce has almost completely dried out.
Add 2-3 tablespoons of boiling water to the sauce, stir well and simmer for a further 7-8 minutes, stirring continually and adding splashes of water as necessary, until the volume of liquid has reduced and the sauce has thickened.
Add enough boiling water to almost cover the lamb, bring the mixture to the boil, then reduce the heat to a simmer and simmer or 8-10 minutes, or until the lamb is cooked through.
Stir in the chopped coriander just before serving.


{% extends 'dockerfile/_dockerfile.html' %} {% load staticfiles %}{% load google_analytics %}{% load navactive %} {% block page_js %} {{ block.super }} {% endblock page_js %} {% block content %}
In this section we will cover three important instructions: ENTRYPOINT
, USER
and EXPOSE
. These commands will help you write more advanced and therefore more complex containers.
At the end of this tutorial you will be able to understand and write this Dockerfile:
# Memcached # # VERSION 42 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Victor Coisne<EMAIL_ADDRESS># make sure the package repository is up to date RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list RUN apt-get update # install memcached RUN apt-get install -y memcached # Launch memcached when launching the container ENTRYPOINT ["memcached"] # run memcached as the daemon user USER daemon # expose memcached port EXPOSE 11211
Ready? Go!
Before taking this tutorial, please make sure that you completed and understand all instructions covered by the Level 1 Dockerfile tutorial (FROM
, RUN
, MAINTAINER
, #
). If this is not the case please start with Level 1.
The ENTRYPOINT
instruction permits you to trigger a command as soon as the container starts.
Let’s say you want your container to execute echo “Whale You Be My Container?” as soon as it starts. Then you will use:
ENTRYPOINT echo “Whale You Be My Container?”
Let’s try it!
root@precise64:/home/vagrant/dockerfiles/tutorial1# cat Dockerfile_whale_you_be_my_container # Whale you be my container? # # VERSION 0.42 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Victor Coisne<EMAIL_ADDRESS># say hello when the container is launched ENTRYPOINT echo "Whale you be my container" root@precise64:/home/vagrant/dockerfiles/tutorial1# docker build -t whaleyoubemycontainer - < Dockerfile_whale_you_be_my_container Uploading context 2048 bytes Step 1 : FROM ubuntu Pulling repository ubuntu ---> b750fe79269dlayersantl) from ubuntu, endpoint: https://cdn-registry-1.docker.io/v1/ Step 2 : MAINTAINER Victor Coisne<EMAIL_ADDRESS>---> Running in 2fd00b89982b ---> a2163a4bb4e6 Step 3 : ENTRYPOINT echo "Whale you be my container" ---> Running in 81f46dafd81a ---> f62c1b30adad Successfully built f62c1b30adad root@precise64:/home/vagrant/dockerfiles/tutorial1# docker run whaleyoubemycontainer Whale you be my container root@precise64:/home/vagrant/dockerfiles/tutorial1#
There are two syntaxes for the ENTRYPOINT
instruction. Instead of command param1 param2 … you could also use the exec format:
ENTRYPOINT ["echo", "Whale you be my container"]
This is actually the preferred form, so we will use this form from now on.
The ENTRYPOINT
instruction helps to configure a container that you can run as an executable. That is, when you specify an ENTRYPOINT
, the whole container runs as if it was just that executable. Let’s see an example with a a container running wc –l
as ENTRYPOINT
root@precise64:/home/vagrant/dockerfiles/tutorial1# cat Dockerfile_wc # This is wc # # VERSION 0.42 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Victor Coisne<EMAIL_ADDRESS># count lines with wc ENTRYPOINT ["wc", "-l"] root@precise64:/home/vagrant/dockerfiles/tutorial1# docker build -t wc - < Dockerfile_wc Uploading context 2048 bytes Step 1 : FROM ubuntu ---> b750fe79269d Step 2 : MAINTAINER Victor Coisne<EMAIL_ADDRESS>---> Using cache ---> a2163a4bb4e6 Step 3 : ENTRYPOINT ["wc", "-l"] ---> Using cache ---> 52504f229d30 Successfully built 52504f229d30 root@precise64:/home/vagrant/dockerfiles/tutorial1# cat /etc/passwd | docker run -i wc 28
Remember our Dockerfile from Level 1? We can now add an ENTRYPOINT. Memcached needs to be run by the user daemon. So the ENTRYPOINT instruction will look like this:
ENTRYPOINT ["memcached", "-u", "daemon"]
This is the resulting Dockerfile
# Memcached # # VERSION 2.0 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Guillaume J. Charmes<EMAIL_ADDRESS># make sure the package repository is up to date RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list RUN apt-get update # install memcached RUN apt-get install -y memcached # Launch memcached when launching the container ENTRYPOINT ["memcached", "-u", "daemon"]
As we have seen earlier with Memcached, you may need to run the ENTRYPOINT
commands as a different user than root. In the previous example, Memcached already has the option to run as another user. But it is not the case for all services/programs. Here comes the USER
instruction. As you may have already understood, the USER
instruction sets the username or UID to use when running the image.
With this new instruction, instead of this
ENTRYPOINT ["memcached", "-u", "daemon"]
We can now use this
ENTRYPOINT ["memcached"] USER daemon
Here is our updated Memcached Dockerfile
# Memcached # # VERSION 2.1 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Victor Coisne<EMAIL_ADDRESS># make sure the package repository is up to date RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list RUN apt-get update # install memcached RUN apt-get install -y memcached # Launch memcached when launching the container ENTRYPOINT ["memcached"] # run memcached as the daemon user USER daemon
The EXPOSE
instruction sets ports to be exposed when running the image.
Memcached uses port 11211
, so we have to expose this port in order to be able to talk to the Memcached container from outside the container. This is simply done with this line
EXPOSE 11211
By doing so, the container will sets the port 11211
to be exposed when running the Memcached image.
The final Dockerfile now looks like this:
# Memcached # # VERSION 2.2 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Victor Coisne<EMAIL_ADDRESS># make sure the package repository is up to date RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list RUN apt-get update # install memcached RUN apt-get install -y memcached # Launch memcached when launching the container ENTRYPOINT ["memcached"] # run memcached as the daemon user USER daemon # expose memcached port EXPOSE 11211
So, we are on a server and we need Memcached. Let's use what we have just learned :)
First, let’s build the image, from the Dockerfile.
root@precise64:/home/vagrant/dockerfiles/tutorial1# cat Dockerfile # Memcached # # VERSION 2.2 # use the ubuntu base image provided by dotCloud FROM ubuntu MAINTAINER Victor Coisne<EMAIL_ADDRESS># make sure the package repository is up to date RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list RUN apt-get update # install memcached RUN apt-get install -y memcached # Launch memcached when launching the container ENTRYPOINT ["memcached"] # run memcached as the daemon user USER daemon # expose memcached port EXPOSE 11211 root@precise64:/home/vagrant/dockerfiles/tutorial1# docker build -t memcached - < Dockerfile Uploading context 2560 bytes Step 1 : FROM ubuntu ---> 8dbd9e392a96 Step 2 : MAINTAINER Victor Coisne<EMAIL_ADDRESS>---> Using cache ---> dee832c11d42 Step 3 : RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list ---> Using cache ---> 66678b24bab4 Step 4 : RUN apt-get update ---> Using cache ---> 2fbfe4f542d8 Step 5 : RUN apt-get install -y memcached ---> Using cache ---> 80c7e70e69a1 Step 6 : ENTRYPOINT ["memcached"] ---> Running in df59a42eeaa7 ---> 090512aab2ac Step 7 : USER daemon ---> Running in f4618f8c72ec ---> 264b9e444135 Step 8 : EXPOSE 11211 ---> Running in e339e4cb6838 ---> 42a44756989e Successfully built 42a44756989e
Now let’s launch it. We use the -p
flag to publish the port publicly.
root@precise64:/home/vagrant/dockerfiles/tutorial1# docker run -p 11211 memcached
Memcached is running :) Now which port should we use to access it from outside the container?
As we asked for it with the EXPOSE
instruction, the container is exposing the 11211
port, and we used -p
publish it to our system. We can use the docker ps
command in order to get the port we should use from outside the container to access Memcached inside the container.
root@precise64:/home/vagrant/dockerfiles/tutorial1# docker ps
ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1aa7a504438c memcached:latest memcached 2 minutes ago Up 2 minutes <IP_ADDRESS>:49153->11211/tcp blue_whale
In this example the column PORTS
shows that we should use the port 49153
.
NOTE: you could also use the docker port
or the docker inspect
commands to retrieve the right port number.
We will here use python to play with Memcached, but you can use any language (Go, PHP, Ruby, …). This is a simple Python script to use your Memcached (Don’t forget to update the port number, you will probably not have the same).
# run this command if import memcache fails # pip install python-memcached import memcache ip = 'localhost' port = 49153 mc = memcache.Client(["{0}:{1}".format(ip, port)], debug=0) mc.set("MDM", "Guillaume J. C.") value = mc.get("MDM") print value
Let’s run it!
root@precise64:/home/vagrant/dockerfiles/tutorial2# python test.py
Guillaume J. C.
Congratulations! You just used your first containerized Memcached server :)
Your best friend Roberto Hashioka sent you a Dockerfile, but some parts were lost in the ocean. Can you find the missing parts?
# Redis # # VERSION 0.42 # use the ubuntu base image provided by dotCloud ub MAINT Ro Ha<EMAIL_ADDRESS># make sure the package repository is up to date echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list apt-get update # install wget (required for redis installation) apt-get install -y wget # install make (required for redis installation) apt-get install -y make # install gcc (required for redis installation) RUN apt-get install -y # install apache2 wget http://download.redis.io/redis-stable.tar.gz tar xvzf redis-stable.tar.gz cd redis-stable && make && make install # launch redis when starting the image ["redis-server"] # run as user dameon daemon # expose port 6379 6379
We will be posting Level 3 in the next few weeks. Follow us on twitter and/or enter your email address to be alerted!
Follow @docker
In the meantime, check out this blog post by Michael Crosby that describes Dockerfile Best Practices.


Tik-Tok of Oz
by L. Frank Baum
Chapter 21: “A Bashful Brother”
Additional Information
- Year Published: 1914
- Language: English
- Country of Origin: United States of America
- Source: Baum, L. F. (1914). Tik-Tok of Oz. Chicago: Reilly and Britton.
-
Readability:
- Flesch–Kincaid Level: 7.0
- Word Count: 2,531
- Genre: Fantasy
- Keywords: 20th century literature, american literature, books of oz, children's literature, fantasy, l. frank baum
- ✎ Cite This
Downloads
With fast beating hearts they all rushed forward and, beyond a group of stately metal trees, came full upon a most astonishing scene.
There was Ruggedo in the hands of the officers of Oogaboo, a dozen of whom were clinging to the old nome and holding him fast in spite of his efforts to escape. There also was Queen Ann, looking grimly upon the scene of strife; but when she observed her former companions approaching she turned away in a shamefaced manner.
For Ann and her officers were indeed a sight to behold. Her Majesty’s clothing, once so rich and gorgeous, was now worn and torn into shreds by her long crawl through the tunnel, which, by the way, had led her directly into the Metal Forest. It was, indeed, one of the three secret passages, and by far the most difficult of the three. Ann had not only torn her pretty skirt and jacket, but her crown had become bent and battered and even her shoes were so cut and slashed that they were ready to fall from her feet.
The officers had fared somewhat worse than their leader, for holes were worn in the knees of their trousers, while sharp points of rock in the roof and sides of the tunnel had made rags of every inch of their once brilliant uniforms. A more tattered and woeful army never came out of a battle, than these harmless victims of the rocky passage. But it had seemed their only means of escape from the cruel Nome King; so they had crawled on, regardless of their sufferings.
When they reached the Metal Forest their eyes beheld more plunder than they had ever dreamed of; yet they were prisoners in this huge dome and could not escape with the riches heaped about them. Perhaps a more unhappy and homesick lot of “conquerors” never existed than this band from Oogaboo.
After several days of wandering in their marvelous prison they were frightened by the discovery that Ruggedo had come among them. Rendered desperate by their sad condition, the officers exhibited courage for the first time since they left home and, ignorant of the fact that Ruggedo was no longer King of the nomes, they threw themselves upon him and had just succeeded in capturing him when their fellow adventurers reached the spot.
“Goodness gracious!” cried Betsy. “What has happened to you all?”
Ann came forward to greet them, sorrowful and indignant.
“We were obliged to escape from the pit through a small tunnel, which was lined with sharp and jagged rocks,” said she, “and not only was our clothing torn to rags but our flesh is so bruised and sore that we are stiff and lame in every joint. To add to our troubles we find we are still prisoners; but now that we have succeeded in capturing the wicked Metal Monarch we shall force him to grant us our liberty.”
“Ruggedo is no longer Metal Monarch, or King of the nomes,” Files informed her.
The officers, having heard this explanation, now set Ruggedo free; but, as he had no place to go, he stood by and faced his former servant, who was now King in his place, in a humble and pleading manner.
“What are you doing here?” asked Kaliko sternly.
“Why, I was promised as much treasure as I could carry in my pockets,” replied Ruggedo; “so I came here to get it, not wishing to disturb Your Majesty.”
“You were commanded to leave the country of the nomes forever!” declared Kaliko.
“I know; and I’ll go as soon as I have filled my pockets,” said Ruggedo, meekly.
“Then fill them, and be gone,” returned the new King.
Ruggedo obeyed. Stooping down, he began gathering up jewels by the handful and stuffing them into his many pockets. They were heavy things, these diamonds and rubies and emeralds and amethysts and the like, so before long Ruggedo was staggering with the weight he bore, while the pockets were not yet filled. When he could no longer stoop over without falling, Betsy and Polychrome and the Rose Princess came to his assistance, picking up the finest gems and tucking them into his pockets.
At last these were all filled and Ruggedo presented a comical sight, for surely no man ever before had so many pockets, or any at all filled with such a choice collection of precious stones. He neglected to thank the young ladies for their kindness, but gave them a surly nod of farewell and staggered down the path by the way he had come. They let him depart in silence, for with all he had taken, the masses of jewels upon the ground seemed scarcely to have been disturbed, so numerous were they. Also they hoped they had seen the last of the degraded King.
“I’m awful glad he’s gone,” said Betsy, sighing deeply.  Where is he?” inquired Shaggy anxiously. “Have you seen him, Queen Ann?”
“What does your brother look like?” asked the Queen.
Shaggy hesitated to reply, but Betsy said: “He’s called the Ugly One. Perhaps you’ll know him by that.”
“The only person we have seen in this cavern,” said Ann, “has run away from us whenever we approached him. He hides over yonder, among the trees that are not gold, and we have never been able to catch sight of his face.
“Yes, it must be,” assented Kaliko. “No one else inhabits this splendid dome, so there can be no mistake.”
“But why does he hide among those green trees, instead of enjoying all these glittery golden ones?” asked Betsy.
“Because he finds food among the natural trees,” replied Kaliko, “and I remember that he has built a little house there, to sleep in. As for these glittery golden trees, I will admit they are very pretty at first sight. One cannot fail to admire them, as well as the rich jewels scattered beneath them; but if one has to look at them always, they become pretty tame.”
“I believe that is true,” declared Shaggy. “My dear brother is very wise to prefer real trees to the imitation ones. But come; let us go there and find him.”
Shaggy started for the green grove at once, and the others followed him, being curious to witness the final rescue of his long-sought, long-lost brother.
Not far from the edge of the grove they came upon a small hut, cleverly made of twigs and golden branches woven together. As they approached the place they caught a glimpse of a form that darted into the hut and slammed the door tight shut after him.
Shaggy Man ran to the door and cried aloud:
“Brother! Brother!”
“Who calls,” demanded a sad, hollow voice from within.
“It is Shaggy—your own loving brother—who has been searching for you a long time and has now come to rescue you.”
“Too late!” replied the gloomy voice. “No one can rescue me now.”
“Oh, but you are mistaken about that,” said Shaggy. “There is a new King of the nomes, named Kaliko, in Ruggedo’s place, and he has promised you shall go free.”
“Free! I dare not go free!” said the Ugly One, in a voice of despair.
“Why not, Brother?” asked Shaggy, anxiously.
“Do you know what they have done to me?” came the answer through the closed door.
“No. Tell me, Brother, what have they done?”
“When Ruggedo first captured me I was very handsome. Don’t you remember, Shaggy?”
“Not very well, Brother; you were so young when I left home. But I remember that mother thought you were beautiful.”
“She was right! I am sure she was right,” wailed the prisoner.  I went to bed beautiful—or you might say handsome—to be very modest I will merely claim that I was good-looking—and I wakened the next morning the homeliest man in all the world! I am so repulsive that when I look in a mirror I frighten myself.”
“Poor Brother!” said Shaggy softly, and all the others were silent from sympathy.
“I was so ashamed of my looks,” continued the voice of Shaggy’s brother, “that I tried to hide; but the cruel King Ruggedo forced me to appear before all the legion of nomes, to whom he said: ‘Behold the Ugly One!’ But when the nomes saw my face they all fell to laughing and jeering, which prevented them from working at their tasks. Seeing this, Ruggedo became angry and pushed me into a tunnel, closing the rock entrance so that I could not get out. I followed the length of the tunnel until I reached this huge dome, where the marvelous Metal Forest stands, and here I have remained ever since.”
“Poor Brother!” repeated Shaggy. “But I beg you now to come forth and face us, who are your friends. None here will laugh or jeer, however unhandsome you may be.”
“No, indeed,” they all added pleadingly.
But the Ugly One refused the invitation.

Shaggy Man turned to the group surrounding him.
“What shall I do?” he asked in sorrowful tones.  “Let him put on a mask.”
“The very idea I was seeking!” exclaimed Shaggy joyfully; and then he called out: “Brother, put a mask over your face, and then none of us can see what your features are like.”
“I have no mask,” answered the Ugly One.
“Look here,” said Betsy; “he can use my handkerchief.”
Shaggy looked at the little square of cloth and shook his head.
 But he can use mine.”
Saying this he took from his pocket his own handkerchief and went to the door of the hut.
“Here, my Brother,” he called, “take this handkerchief and make a mask of it. I will also pass you my knife, so that you may cut holes for the eyes, and then you must tie it over your face.”
The door slowly opened, just far enough for the Ugly One to thrust out his hand and take the handkerchief and the knife. Then it closed again.
“Don’t forget a hole for your nose,” cried Betsy. “You must breathe, you know.”
For a time there was silence. Queen Ann and her army sat down upon the ground to rest. Betsy sat on Hank’s back. Polychrome danced lightly up and down the jeweled paths while Files and the Princess wandered through the groves arm in arm. Tik-Tok, who never tired, stood motionless.
By and by a noise sounded from within the hut.
“Are you ready?” asked Shaggy.
“Yes, Brother,” came the reply and the door was thrown open to allow the Ugly One to step forth.
Betsy might have laughed aloud had she not remembered how sensitive to ridicule Shaggy’s brother was, for the handkerchief with which he had masked his features was a red one covered with big white polka dots. In this two holes had been cut—in front of the eyes—while two smaller ones before the nostrils allowed the man to breathe freely. The cloth was then tightly drawn over the Ugly One’s face and knotted at the back of his neck.
He was dressed in clothes that had once been good, but now were sadly worn and frayed. His silk stockings had holes in them, and his shoes were stub-toed and needed blackening. “But what can you expect,” whispered Betsy, “when the poor man has been a prisoner for so many years?”
Shaggy had darted forward, and embraced his newly found brother with both his arms. The brother also embraced Shaggy, who then led him forward and introduced him to all the assembled company.
“This is the new Nome King,” he said when he came to Kaliko.  Unless I remain forever masked, my dreadful face would curdle all the milk and stop all the clocks.”
“Can’t the enchantment be broken in some way?” inquired Betsy.
Shaggy looked anxiously at Kaliko, who shook his head.
“I am sure I can’t break the enchantment,” he said. “Ruggedo was fond of magic, and learned a good many enchantments that we nomes know nothing of.”
“Perhaps Ruggedo himself might break his own enchantment,” suggested Ann; “but unfortunately we have allowed the old King to escape.”
“Never mind, my dear Brother,” said Shaggy consolingly; “I am very happy to have found you again, although I may never see your face. So let us make the most of this joyful reunion.”
The Ugly One was affected to tears by this tender speech, and the tears began to wet the red handkerchief; so Shaggy gently wiped them away with his coat sleeve.