►
From YouTube: Red Hat Quay Proxy Pull-thru Caching Demo
Description
In this demo you will learn how Red Hat Quay can be used as a transparent cache for external registries to greatly improve image pull performance and selectively provide access to public registries.
This is one of the new features of Red hat Quay 3.7, be sure to also check out the other new features in our launch blog post here: http://content.cloud.redhat.com/blog/red-hat-quay-3.7-introduces-caching-storage-quotas-more
A
A
A
Let's
now
switch
to
the
query:
ui
we're
going
to
create
a
new
organization
and
configure
it
as
a
cache
for
another
registry.
I'll
simply
call
it
cache.
For
the
sake
of
brevity,
the
actual
name
doesn't
really
matter,
and
you
can
have
an
arbitrary
number
of
cache
organizations
in
quay
to
cache
different
registries
to
turn
an
organization
into
a
cache.
We
are
going
to
switch
to
the
settings
panel
of
the
organization
and
enter
the
domain
name
of
the
remote
registry
to
be
cached.
In
this
case
quay.io
optionally.
A
We
could
enter
credentials
for
the
registry
here
or
leave
them
out
to
pull
anonymously
from
credit
io.
The
expiration
time
settings
control
when
cached
images
would
expire
and
subsequently
be
evicted
from
the
cached.
The
default
is
24
hours.
Here,
I'm
fine
with
this,
and
by
clicking
save,
we
are
completing
the
configuration
process
and
the
organization
is
now
a
cache.
A
From
now
on.
From
the
client
perspective,
this
is
a
read-only
organization.
You
cannot
push
to
this
organization
or
create
new
content
within
it.
You
can
only
pull
through
the
organizations
in
the
form
of
a
cache
before
we
use
it,
though,
we
can
take
a
last
look
at
the
contents
and
see
that
currently
there's
nothing
there.
A
I'm
now
going
to
put
an
image
through
the
cache
from
my
own
query
registry.
First,
let
me
also
show
you
that
I
have
currently
no
images
in
my
local
partner
environment
either.
Now,
let's
say
I
want
to
pull
the
community
version
of
quay
security
scanner,
clear,
which
is
available
in
cuetodio,
slash
project
quay,
slash
clear
to
pull
that
image.
A
As
you
can
see,
the
pool
succeeds
as
it
would
normally
do,
but
here's
what
happened
in
the
background
when
I
attempted
to
pull
from
quay.method.o
cache,
slash
project
quay,
slash,
clear,
quave,
recognized
that
this
is
actually
a
cache
organization
and
it
subsequently
checked
first
whether
the
desired
image
was
already
in
the
cache
since
the
cache
was
empty.
At
this
point
in
time,
I
pulled
the
image
from
the
configured
remote
registry
by
appending
the
path
of
the
desired
image
within
the
cache
organization
to
the
domain
of
the
remote
registry
craig.io.
A
A
A
A
A
A
A
In
this
example,
we
have
cached
an
entire
registry
like
quay.o.
That
means
any
image
that
is
accessible
there
can
be
accessed
through
my
cache.
This
may
not
be
desired.
Sometimes
sometimes
you
only
want
to
allow
access
to
a
certain
portion
of
a
remote
registry
through
a
cache
and
with
quay.
You
can
do
that
as
well.
Let's
return
to
the
settings
menu
of
our
cache
organization
and
reset
its
configuration.
A
A
A
Again,
the
pool
succeeds,
and
I
have
the
postgres
image
available
locally
to
prove
that
it
originally
came
from
docker
hub.
I
can
also
attempt
to
pull
the
image
directly
from
there.
The
pull
attempt
from
docker
finishes
fairly
quickly
because
the
image
and
all
its
layers
are
already
present
as
a
result
of
the
previous
pull
through
of
my
cache,
I
can
also
see
the
postgres
image
now
in
my
cache
organization,
this
time
without
the
full
path,
since
my
cache
only
covers
the
library
project
in
docker
hub.
A
While
at
the
network
layer,
access
to
docker
might
be
blocked,
it
can
be
exposed
by
gray
through
a
pull-through
cache
at
the
very
granular
level.
The
only
caveat
here
is
that
developers
need
to
know
about
this
and
the
location
of
the
cache
and
therefore
adjust
all
their
pulse
backs
with
portman.
There
is
a
nice
way
to
circumvent
this.
You
can
edit
the
registries.conf
file
of
your
apartment
installation
and
enter
the
following
configuration
segment.
A
It
essentially
makes
podman
redirect
all
pool
attempts
to
the
dockerhub
library
project
towards
our
cache
organization.
Let's
run
with
this,
if
we
now
attempt
to
put
another
image
from
dockerhub's
library
project
directly,
it
will
be
transparently
pulled
through
our
cache.
Even
though
the
pull
specs
had
docker,
I
o
library
engine
x.
In
this
example,
we
can
see
the
result
in
our
registry.
The
nginx
image
is
now
cached
there
as
well.
A
Another
nice
feature
of
portland
is
that
it
normalizes
docker
hub
references.
So
in
your
pull
command,
you
can
actually
omit
the
library
path,
like
I'm
doing
here
when
putting
redis.
This
is
very
popular
in
beginner
tutorials
for
learning.
Containers
portman
knows
how
to
interpret
this
for
dr
hub
and
changes
it
transparently
to
docker,
dot,
io
library,
slash
redis,
which
in
turn
causes
it
to
be
pulled
through
our
cache.