►
From YouTube: Accelerate the Path to Production with Fabric Topologies
Description
A virtual meetup hosted by Hyperledger Denver on January 26, 2023 featuring Alex Olaru and Taylor Trott from Alphaledger speaking about accelerating the path to production with Fabric Topologies.
Did you get your first Fabric samples test network up and running and created the first smart contracts? Are you starting to plan for a production deployment and are not sure about the main items to consider for a production deployment? Are you already in production but are encountering challenges with expanding the deployment because of security, scaling, and/or operational concerns?
If any of these apply to you, please join Alex Olaru and Taylor Trott from Alphaledger as they present and run demos of working examples based on the recently released Hyperledger Lab: Fabric Topologies. These topologies demonstrate more advanced/newer Fabric features such as:
· End to end Mutual TLS between Fabric Components
· World State with CouchDB Clusters and Fauxton DB Console
· Channel Participation API with no System Channel
· How to Proxy and increase redundancy for Fabric Components
· Deploy Chaincode as an External Service
· Boostrap a Fabric CA with Identities from an LDAP Store
· Easy Smoke Test for HL Fabric versions changes
The end of the webinar will conclude with a poll and discussion with the community to evaluate areas of interest for the build out of future topologies and working examples of other Fabric features.
To learn more about the Fabric Topologies lab, check out their repo at: https://github.com/hyperledger-labs/fabric-topologies
----
Hyperledger – Open Source Blockchain Technologies
Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use
Discord: https://discord.gg/rVCn4j7UFd
Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory
Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter
Follow-us on Twitter @Hyperledger
Learn about Hyperledger Membership: https://www.hyperledger.org/about/join
#Hyperledger #Blockchain
License
Creative Commons Attribution license (reuse allowed)
B
So
the
main
thing
what
I'll
say
to
you
is
as
we
move
through
their
presentation
today.
Please
feel
free
to
use
the
chat
to
post
any
questions
that
you
have
and
as
we
can
get
them
in,
you
know
right
with
the
presentation,
we'll
do
that
and
then
definitely
at
the
end
of
their
presentation,
we're
going
to
go
in
and
do
a
nice
q
a
as
well
so
at
this
point
I'm
going
to
turn
it
over
to
Taylor
and
Taylor.
Why
don't
you
walk
us
through
this
great
presentation.
C
C
And
let
me
just
move
this
out
of
the
way
a
little
bit
here
so
about
Alpha
Ledger
Alpha
Ledger
is
developing
blockchain
based
infrastructure
for
the
fixed
income
Market
to
originate
bonds,
but
we
both
do
loans.
Insecurities
Alpha
Ledger
was
founded
in
2019
with
a
mission
to
bring
transparency,
traceability
and
increased
access
to
the
bond
market.
C
C
So
the
first
reason
we
were
we're
trying
to
come
up
with
a
production,
ready
system,
and
so
we
wanted
to
address
some
important
points.
One
of
those
is
secure,
communication
between
the
nodes
and
the
network,
part
of
sock
2
and
the
finance
industry
that
require
like
they
require
encryption
at
rest
and
encryption
over
Transit.
C
How
do
we
go
about
integrating
that
or
even
just
what
does
this
new
feature
do,
and
so
those
are
the
main
points
for
production,
Readiness
and
so
after
the
other
point
is
there
was
there
was
lots
of
online
tutorials
and
there's
lots
of
documentation.
I
think
one
of
the
main
things
is
that
you
know
lots
of
these
are
are
sort
of
scattered
and
they're
on
different
operating
systems,
sometimes
the
the
blog
will
be.
You
know
using
Mac
and
sometimes
windows
and
sometimes
Linux.
D
So
we
have
at
the
top.
We
have
a
topologies
folder
and
we're
saying
that
the
ball,
that
each
of
the
topologies
is
basically
self-contained.
What
that
really
means
is
that
everything
needed
for
running
a
topology
is
located
in
that
topology
folder,
the
only
exception
to
that
are
some
basic
or
some
very
basic
or
common
components
that
we
use
across
all
topologies,
namely
as
part
of
dock
and
compose.
We
have
a
network
that
is
configured
with
a
different
name
for
each
topology,
so
that's
kind
of
the
first
Docker
compose
base
file.
D
Then
we
have
a
show
command,
which
basically
it's
a
a
service
that
actually
is
used
across
all
topologies,
and
what
this
does
any
commands
that
we
need
to
run
for
executing,
let's
say
committing
some
chain
code
or
invoking
some
chain
code
register,
uses
users
or
things
that
nature,
even
those
run
inside
a
Docker
container.
So
nothing
runs
on
the
com.
Nothing
runs
on
the
host.
If
you
will,
everything
is
Docker
based,
so
the
two
prerequisites
for
running
the
tapal.
D
You
know
the
topologies
is
to
to
have
Docker
and
Docker
compose
installed
now
inside
the
topology
folder.
What
you'd
have
you
have
two
basic
scripts,
a
setup
script
and
a
tear
down
the
setup.
Basically
has
all
the
screen,
all
the
commands
necessary
to
bring
up
to
bring
up
the
network.
In
fact,
you
will
see
right
now
that
I
just
brought
up
one
of
the
networks,
so
topology
number,
four
it
just
came
up.
D
We're
gonna
go
a
little
bit
more
to
see
kind
of
what
what
it
means,
but
in
essence,
if
a
topology
has
started
up,
you
would
see
at
the
end
that
it
completed.
You
would
get
a
message
of
this
nature
and
it
also
shows
that
sorry.
It
also
shows
at
the
end
of
the
fact
that
we
have
loaded
a
that
we
did
a
get
command
an
invoke
command
to
read
the
assets
from
the
from
the
network.
D
D
All
the
setup
of
the
I
mean
the
the
network
basically
has
one
single
channel
that
all
peers
are
joining
for
the
different
organizations
and
the
there
is
one
topology
in
which
case
in
which
orders
are
also
joining
the
same
channel.
We're
going
to
get
to
that
last
apology.
At
the
end,
that's
the
topology
that
used
to
use
the
system,
participation,
the
channel
participation
API,
so
just
to
come
back
a
little
bit
to
some
of
the
other
configurations.
D
So
the
setup
you
know
again
runs
all
the
scripts
necessary
to
set
up
the
network
that
they're
done
will
will
basically
take
everything
down
for
for
that
topology.
The
only
thing
that
is
going
to
remain
on
your
machine
is
the
image
that
got
pulled
into
the
dot
into
the
docker
in
your
Docker
repository,
and
the
reason
for
that
is.
We
want
to
allow
it
to
kind
of
start
up
more
easily.
So
the
only
thing
you
would
really
need
to
clean
up
that
the
teardown
doesn't
do
is.
D
Are
the
images
inside
docker
crypto
material
for
all
the
components
in
the
network
are
are
created
in
descriptive
material
folder,
so
you
can
kind
of
walk
through
it
and
then
you
will
see
for
each
of
the
components.
You
know
the
the
MSP
folder
with
the
the
certificates,
the
the
keys
and
things
on
nature
and
the
caca
sorts
as
well.
D
We
mentioned
that
we
can
run
multiple
topologies
at
the
same
time
and
those
topologies
can
even
run
with
different
fabric
binaries.
The
way
that's
achieved
is
through
this
EnV
file.
This
configuration
file
where
for
each
topology
you
can
go
and
actually
adjust
the
fabric
version
that
you
want
to
run
for
for
each
of
these
components.
Obviously
you
know
the
the
topology
will
use
a
certain
features,
for
example
Channel
participation.
D
D
This
is
an
important
one,
so
when
we
run
inside
of
a
script
just
to
come
back
really
quick,
when
you
see
a
Docker
compose,
it's
actually
kind
of
layering
three
different
three
different
Docker
compose
files
is
this
base,
one
that
we
mentioned
at
the
end
and
then
the
one
for
the
shell
command,
and
then
there
is
the
docker
compose
that
it's
set
up
in
each
single
topology
and
then
inside
it.
What
you'll
find
here
that
the
ports
are
pretty
much
all
commented
out.
D
So
what
that
means
is
that
no
ports
of
the
containers
are
running
are
actually
exposed
externally
to
the
host
by
default.
The
reason
for
that
is
kind
of
two-fold
one.
We
didn't
want
to
conflict
with
any
ports
that
might
actually
be
ordered
to
be
taken
on
the
machine.
We
wanted
to
make
sure
that
the
network
starts
up
with
our
problems
or
without
any
issues.
D
You
know
due
to
this
the
power
conflict
and
secondly,
if
you
want
to
have
actually
multiple
networks
running
concurrently,
it
gets
a
little
bit
trickier
because
then
each
topology
would
have
to
have
its
own
port,
for
example,
for
a
a
CA
and
things
that
nature.
So
we
left
it
here
for
the
users
to
to
make
adjustments
say
they
see
fit
and
just
open
the
the
ports
that
they
need
for
certain
components
just
at
the
startup
time
and
when
they,
when
they
start
up
a
network.
D
In
fact,
we'll
see
I'll
just
show
two
examples
right
now,
because
they're
going
to
come
up
and
we're
going
to
be
doing
some
testing
so
in
this
case,
I
open
a
port
for
postgres,
because
one
of
the
topologies
we're
going
to
review
later
deals
with
storing
data
for
the
fabric
CN
postgres.
So
we
want
to
be
able
to
browse
some
data
and
postgres.
So
therefore,
we
open
that
port
and
later
on,
for
example,
here
for
couchdb
I'm,
sorry
for
open,
ldap
or
open
ldap
we're
using
that
to
also
one
of
the
apologies.
D
D
Let
me
see
what
else
then
we
can
cover
here.
So
there
is
a
lot
of
repetition
actually
in
terms
of
what
the
setup
scripts
does
if
you
were
to
look
from
one
topology
to
another.
So
the
setup
script,
for
example,
for
T3
to
T1,
would
be
looking
very
similar
with
just
a
few
changes
right
and
the
reason
we
didn't
want
to
move
this
kind
of
common
things
to
like
higher
level.
Common
components
was
because
we
wanted
to
allow
for
comparison
between
topologies.
D
So
in
this
case,
what
I'm,
looking
here,
it's
a
a
comparison
between
topology,
T1,
anthropology,
T3,
so
T1
is
the
base.
One
that's
Taylor
has
been
talking
about.
T3
I
think
is
the
one
that
deals
with
this
external
chain
code.
So
this
is
making
it
easy
now,
because
we
can
actually
find
out
okay,
what
were
the
new
files,
the
new
configurations
we
had
to
set
up
or
what
did
we
need
to
change,
for
example,
in
a
yml
file
right
for
for
Docker,
compose
oops,
I?
D
Well,
I'm
going
to
open
it
up
again
or
a
script
right,
like
I
mentioned
the
setup
script.
What
is
the
difference
between
T1
versus
D3?
So
we
think
that
that
makes
makes
the
understanding
of
changes
that
they
have
to
be
have
to
be
made
because
there's
in
some
instances,
there's
quite
a
few
changes.
It
makes
it
easier
to
understand
the
differences
between
topologies.
D
D
C
C
We
have
these
green
boxes
representing
each
organization
within
each
organization,
you're
going
to
see
various
blue
boxes
which
represent
the
different
Services
running
so,
for
example,
org
one.
We
have
an
orders
service
running,
we
have
a
certificate,
Authority
service
running
or
two.
We
have
peers
certificate
authorities
org3.
We
have
peer
certificate
authorities
and
So
within
the
blue
boxes.
We
have
like
individual
I
would
call
like
nodes.
Maybe
you
see
Individual
Services
and
also
you
can
see
they
give
you
each
each.
Maybe
has
a
little
more
detail
like
on
this
pier.
C
You
can
see.
It
says
level
DB
internal
chain
code,
and
then
you
can
see
right
here.
It
says
Pier
1
CLI,
so
it's
it's
quite
detailed
and
and
each
one
of
these
diagrams
and
under
the
certificate
authorities
box
inside
the
box.
You
can
see
that
there's
two
gray
boxes
and
the
first
one
that
says
Fabric
catls
and
the
second
one
says:
fabric
CA
identities.
C
The
the
fabric
TLS
is
responsible
for
issuing
the
search
for
the
communication,
secure
Communications
between
the
orgs
and
the
membered
nodes
and
the
fabric
CA
identity
service,
for
the
issuing,
the
certificates
to
for
the
endorsements
of
chain
code
and
such
so
this
is
a
or
this
is
T1,
and
so
we'll
we'll
look
next
at
t
zero,
so
t0
is
sort
of
T1
minus
of
one.
So
it's
minus
or
three
we've
reduced.
C
And
so
let
me
just
go
to
the
next
one
here,
so
this
is
more
interesting
here.
So
T2
we
have
additional
orders
and
peers,
so
we've
we've
taken
and
we
have.
We
also
have
some
other
improvements
or
I'll
get
to
that,
but
we
have
additional
orders
included
under
the
other
org
org2,
and
on
top
of
that,
we've
also
added
nginx
proxies.
C
C
Rather
than
use
mode,
I
wanted
to
show
you
the
nginx
proxies
here
so
we'll
go
to
T2,
go
to
the
configuration,
and
you
can
see
right
here,
there's
an
orderish
proxies
and
peers
proxies.
So
there's
proxies
and
and
for
example,
here's
the
order,
orders
proxy
configuration
for
nginx.
So
we
have
a
configured
so
that
it
will
it's
like
a
pass
through
and
it's
using
like
SSL.
C
C
D
C
C
C
C
C
There
is
a
core
yaml
file
that
needs
to
be
updated
to
points.
So
this.
If
I
go
into
this
file,
you
basically
have
to
point
to
this
build
pack
and
say
that
you're
using
the
external
build
pack,
and
then
we
have
the
external
chain
code,
Docker,
container
definitions.
Here,
we've
modified
the
peer
configuration
a
little
bit
and
some
of
the
scripts
have
changed
so
there's
some
there's
a
lot
of
probably
I
would
say
slight
differences
in
how
the
chain
code
gets
installed.
There.
C
D
All
right
so
T4
this
one
deals
with
a
configuration
on
ldap
store.
So
if
you
happen
to
have
worked
with
fabric
CAA,
you
know
that
there
are,
as
Taylor
mentioned.
There
are
two
type
of
sets
of
crypto
materials
that
are
being
created
right,
some
for
SSL
communication,
but
others
for
identities
for
each
of
the
nodes
in
the
network.
D
D
Now
there
is
some
support
with
Fabrics
here
whereby,
instead
of
having
to
register
with
this
users,
these
identities
with
fabric
CA,
you
can
actually
kind
of
hydrate
it
or
see
them.
If
you
will
from
an
ldap
store,
so
you
can
actually
configure
then
the
fabric
CA
to
work
and
connect
to
an
ldap
store.
D
So
if
you
start
up
that
topology
D4,
you
will
get
as
part
of
the
setup
a
container
for
open
ldap
and
that
container
will
be
configured
to
load
its
startup
time
organization,
organizational
units
from
this
ldif
file
and
then
also
counts
that
sit
under
those
organizational
organizational
units
right.
So
this
is
the
base
domain,
the
domain
controller
and
we'll
take
a
look.
You
know
in
a
second
how
how
that
you
know
how
looking
inside
open
ldap
the
fabric
CA
is
configured.
D
There
is
an
ldap
configuration
if
you
looked
at
the
fabric
server
configuration
there
is
a
section
for
turning
on
ldap.
So
if
you
turn
on
ldap,
then
you
can
have
it
connect
to
a
so
on
to
a
open,
ldap,
Repository
or
ldap
compliant
part.
Three.
So
again,
in
this
case,
we
basically
have
a
container
right,
exposing
on
that
Port,
that's
the
base
domain
and
then
what
you
see
this
long
string
is
basically
a
user
right
to
connect.
D
It's
like
a
bind
user.
If
you
will,
is
the
user
and
the
password
to
connect
with
to
that
to
that
store.
So
if
we
look
with
J
Explorer,
this
is
basically
for
org
one.
We
have
kind
of
two
or
used
right
organizational
units,
one
for
identities,
the
other
one
for
TLS
identity
is
probably
the
more
important
one,
and
then
here
you'll
see
the
users
that
we've
kind
of
loaded
from
their
ldif
file
right.
D
D
So
that's
on
the
ldap
held
up
configurations
if
we
go
next
to
T5,
staying
with
fabric
Cas.
Sorry
I
forgot
to
show
here,
but
basically
this
is
the
open
ldap
right.
That
kind
of
supports
both
of
these
organizations.
If
we
were
to
go
now
and
look
at
fabricate
clustering,
so
Fabrics
here
I
mentioned
it-
has
a
database,
a
relational
database
to
store
state
user
certificates
and
things
that
nature
that
database
is
sqlite.
It
can
actually
be
configured,
though,
with
with
postgres
and
I
think
MySQL
as
well.
D
Now,
what
would
why
would
we
want
to
do
that?
Is
it
just
in
case?
If
we
want
to
provide
failover
for
a
fabric
CA
component
right,
we
can
actually
have
now
two
two
nodes
for
fabric
CA,
working
with
the
same
set
of
users
and
credentials
and
using
postgres
behind
the
scenes
to
store
their
data.
That's
not
possible
SQL
alert
right
with
postgres.
You
can
also,
you
know,
use
a
cloud
service
or
you
know
you're
not
limited
to
sqlite.
You
can
almost
view
it
like
an
embedded
database
right,
not
very
Enterprise
scale.
D
So
what
we
have
here,
we
have
a
postgres
server
with
two
databases
in
it,
one
that
supports
TLS
the
other
one
that
supports
the
identities.
So
I
have
I
showed
earlier
right
now
like
how
we
expose
the
port
for
that
T5.
I.
Think
right
so
we're
exposing
this
five
four
three
four
in
postgres
and
then,
if
we
go
with
a
query
tool,
we
basically
can
see
here
that
we
have
two
databases:
a
fabric,
catls
and
identities.
D
D
D
However,
if
you
were
to,
for
example,
have
a
network
where
you
have
nodes
communicating
over
the
public
internet
and
there
is
no
point-to-point
like
a
VPN
connection.
In
that
scenario,
and
probably
many
other
scenarios
too,
it's
very
recommended
that
you
actually
have
nodes
authenticated
to
each
other
through
client
authentications
right.
So
that's
what
kind
of
mutual
TLS
means
you
know:
client,
authentication,
SSL
or
two-way
SSL.
However,
you
want
to
call
it
so
what
we've
done
with
this
one
we've,
basically
enable
client
authentication
across
all
the
different,
all
the
different
components.
D
So
if
you
were
to
look
at
scripts
again,
you
could
see
this
with
the
div
to
D1.
So,
for
example,
when
we
commit
chain
code,
you
see
this
parameter
client
auth
right.
So
you
wouldn't
see
that
in
T1,
because
we
don't
use
client
authentication.
But
what
it
means
here
is
that
this
administrator
account
when
it
invokes
this
command.
It
connects
right
to
peers
and
orders
and
so
forth
it
authenticates
itself
and
the
way
it
authenticates
itself
is
with
this
parameter
and
then
it
it
has
a
certificate
and
a
key
file
and
certificate.
D
The
certificate
gets
sent.
You
know
during
the
SSL
headshank
gets
sent
to
the
server,
and
the
server
then
can
verify
that
it's
signed
the
certificates.
It's
signed
by
a
known
certificate
authority
to
that
server,
and
so
this
way
you
know
we
can
make
sure
that
only
only
nodes
or
only
all
the
entities
that
are
allowed
to
connect
to
those
components
inside
the
the
network
you
know,
can
actually
do
work
with
them.
D
You
know
so
again,
very
important
for
for
secure
Communications
across
the
internet,
in
fact,
even
like
2.4
I
think
some
of
the
commands
in
2.4
actually
require
required
client
of
by
default.
So
it's
a
good
thing
to
learn
about
anyway,
t7
private
data
collections.
This
basically
deals
with
sorting
data
off
of
the
public
Channel,
so
data
that
is
maybe
private
to
a
certain
org
or
a
set
of
organizations.
D
So
what
this
does
it?
Basically
configures
some
private
data
collections
and
there
is
some
data
that
gets
stored
in
this
private
data
collection.
So
if
we
were
to
look
again
at
configurations
when,
let's
say
when
we
approve
some
chain
code,
one
organization
approves
this
chain
code.
Sorry
we
have
to
go
to
D7,
so
in
D7,
if
I
was
took
again,
this
scripts
I
forgot
to
mention
this.
All
these
scripts
get
called
from
the
main
setup
right,
so
that's
kind
of,
but
we
just
wanted
to
have
it
a
little
bit
more
modularized.
D
If
you
will
so
that's
why
we
have
been
separately
here
so
in
the
approve,
you
can
see
that
there
is
a
collections
config
right
that
gets
passed
to
the
approved
if
I'm
not
mistaken.
This
is
the
collections
config.
So
you
can
see.
This
is
how
you
define
a
PDC
private
data
collection.
In
this
case,
it's
a
PDC
that
only
this
member
has
access
to
feed
and
write,
and
then
you
could
see
then
in
the
chain
code.
D
Again,
this
is
the
basic
chain
code
that
we
have
from
that
is
part
of
the
distribution,
the
fabric
distribution.
So
here
we
we
basically
store
the
assets
if
you
will
on
the
main
Channel,
but
we
also
put
data
into
the
private
data
collection,
so
we
put
some
with,
for
example,
in
this
case,
I
guess
we're
putting
also
the
same
thing
the
asset
but
we're
putting
in
the
private
data
collection
right.
So
there's
a
put
for
private
data
yeah.
So
that's
how
we
we
leverage
the
private
data
collection
all
right.
D
So
let's
go
next
to
T8,
so
the
T8,
the
it's
a
cluster
couchdb
configuration
we
think
one.
This
is
probably
one
of
the
most
important
ones
as
you.
As
you
know,
state
in
hyper
Ledger
fabric
is
represented
by
two
types
of
data
storages.
If
you
will
so
you
have
things
like
the
the
blocks
themselves
right,
they
kind
of
get
stored
with
the
orders
and
they
get
can
be
pulled
with
the
peers
and
so
forth.
D
So
that's
kind
of
the
chain
right
of
changes
that
happen
over
time,
but
then
you
have
the
world
state,
so
the
world
State
represents.
What's
the
current
state
of
any
record
that
you
store
in
in
on
on
the
blockchain
network
by
default,
the
database
used
for
storing
that
straight
is
called
level
DB
and
I
kind
of
view.
It
again
as
more
like
an
embedded
database
works.
D
But
again
we
we
like
to
look
at.
What's
the
data
inside,
you
know
that,
like
a
store,
maybe
balance
some
numbers-
maybe
you
know,
do
a
query
or
two
not
very
fancy
in
terms
of
analytics
or
queries,
but
just
kind
of
get
a
sense
of
you
know
what
do
what
we
have
as
far
as
data
in
the
blockchain
right,
because
otherwise
everything
can
just
kind
of
seem
like
a
black
box
and
it's
you
know
hard
to
show
a
user.
D
You
know
what's
inside
a
blockchain,
so
for
our
deployments
we
use
heavily
couchdb
and
we
externalize
couchdb.
It
runs
its
own
container,
I
mean
when
you
talk
about
kubernetes
and
things
like
nature.
I
mean
it's
very
nice
because
then
you
can
have
dedicated
storage.
You
know
different
iops
I
mean
you
can
treat
it
more
like.
D
You
know,
Enterprise
database,
if
you,
if
you,
if
you,
if
you
use
cloudsdb
as
an
external
database,
so
in
this
case
for
Pier
one
we're
using
couchdb
instances
and
we
actually
have
two
of
them
and
we
have
a
clustering
set
up
for
them.
So
that's
actually
quite
useful.
If
you
want
to
see
how
I
mean
there's
manuals,
of
course
in
couchdb
on
how
to
set
up
couchtv,
but
this
is
a
working
example
of
a
of
a
cluster
and
then
it's
accessed
by
pr1
through
the
scarsdb
proxy
right.
D
D
Okay,
here
they
are,
and
now,
if
I
want
to
see
them
in
the
database
couchdb,
we
have
two
nodes
yeah.
We,
if
you
remember
the
ports
again
actually
now
this
one.
Actually
we
left
by
default.
The
couchdb
is
the
only
one
that,
even
if
you
look
in
the
repository,
it's
actually
the
only
one
that
has
external
ports
already
mapped.
D
D
D
You
know
nowhere
close
to
like
a
relational
database,
but
you
know
there
are
some
things
that
can
be
done
in
terms
of
performance,
tuning
and
and
configurations
for
for
couchdb,
and
of
course
this
is
the
just
the
same
view,
but
from
the
second
node
and
then,
if
you
were
to
go
to
like
config,
you
can
see
here
right.
It
says
that
it
seems
that
you're
running
a
cluster
with
two
nodes.
D
So
for
this
kind
of
settings
you
know
they
don't
let
you
to
do
configurations
through
the
UI
and
then
you
kind
of
have
to
put
them
through
the
configuration
files
yeah.
So
again,
we
think
probably
this
is
one
of
the
most
important
ones
in
our
view.
As
far
as
you
know,
from
all
of
this
you
know
I
guess:
I
will
look
at
the
mutual
TLS
and
these
ones
are
probably
the
the
ones
that
are
most
important.
D
We
think
for
Enterprise
deployments
and
then
going
to
the
next
one
and
the
last.
This
is
the
channel
participation
API
again
a
newer
version.
I
think
it's
to
2.4
that
it
got
fully
implemented
in
this
configuration.
What's
nice
about
it,
there
is
no
more
need
for
a
system
Channel,
so
prior
versions
right,
you
have
to
have
a
system
Channel
set
up
first
and
all
orders
have
to
join
to
a
additional
configuration
import
back
to
perform,
and
so
a
bunch
of
things
that
you
know
are
not
not
very
useful.
D
Maybe
so
it's
very
nice
that
the
team
at
fabric
came
up
with
this
approach
of
child
participation
API,
which
means
that
just
the
way
up
here
joins
a
channel
orders
do
the
same
right,
so
you
can
have
an
order
joining
two
different
channels
right
and
it
just
becomes
a
lot
more
scalable
and
in
many
ways
you
know
easier
to
configure.
So
the
way
you
would
see
that
what
we
have
here
is
go
back,
so
we
have
in
orb
one.
We
have
three
orders.
D
So
if
we
go
to
the
org
one
scripts
for
joining
channels,
because
you
might
wonder
right
or
or
one
has
no
peers,
what
are
we
joining
well,
his
order
is
now
they're
being
joined,
so
this
is
a
newer
Command
right,
osm
admin
or
order
service,
no,
the
admin
and,
as
you
can
see
here,
we're
joining
we're
joining
the
same
channel
that
the
peers
would
join
again.
A
working
example
of
how
child
participation
can
be
set
up
with
this
said
I
think
we
have
10
more
minutes.
D
B
D
B
A
B
B
B
C
D
So
in
the
topology
is
everything
it's
well
I,
wouldn't
say
necessarily
self-signed,
because
the
certificates
are
signed
by
the
the
ca
certificate
that
comes
with
fabric
CA.
So
but
the
Fabrics
is
self-signed
its
own
certificate
and
then
it
uses
that
CA
certificate
to
sign
the
certificates
for
the
identities,
for
example
right
now
to
plug
in
a
external
one,
I
mean
that
is
possible
as
well,
but
in
that
case
you
have
to
deploy
inside
of
the
crypto
material
folder.
You
would
have
to
deploy
your
own.
Your
own
certificates.
D
D
D
D
D
Mention
that
when
open
ldap
is
used
or
an
ldap
compliance
store
is
used
to
hold
identities.
That's
keeps
the
need
for
having
to
register
identities,
but
you
still
need
to
do
enrollments
in
order
to
issue
certificates.
You
know
to
to
use
for
communication,
you
know,
and
to
have
your
Ms
people,
that's
popular
with
them
again.
This
is
just
one
approach.
I
know
the
fabric
team
actually
is
using
is
looking
at
kind
of
other.
Maybe
kubernetes
based
mechanisms
to
generate
certificates,
so
fabric
is
CA,
is
not
the
only
one
where
you
can
generate
certificates
right.
C
D
Oh
yeah
I
mean
that's
so
yeah
I
mean
that's
what
we
do.
You
know
in
our
case,
right
I
mean
we
have
you
know
we're
actually
trying
to
set
up
across.
You
know
multiple
Cloud
providers,
you
know
Network
I
mean
components
talking
to
to
each
other.
The
purpose
of
the
topology
is
is
to
to
allow
you
to
kind
of
allow
users
to
understand.
D
You
know
how
these
nodes
communicate
with
each
other
and
where
configurations
have
to
be
made,
but
yeah
it's
certainly
possible
when
you,
when
you
do
your
initial,
for
example,
when
you
create
the
initial
channel
right
and
then
you
have
to
specify
orders,
so
those
Auditors
can
have
their
own
domains
living.
You
know
those
those
nodes
can
be
in
different
different
networks
right
and
they
can
talk
to
each
other
over
the
internet.
D
Darker
less
without
Docker
I
mean
even
like
with
kubernetes.
Right
still,
you
could
say
you
still
kind
of
need
some
darker
right
configurations.
It's
it's
not
that
kind
of
means.
You
know
you
you
can
handle
it
with
ansible
Chef
right.
You
can
do
the
setup.
You
can
run
them
on
bare
metal.
It's
there's
no
need
you
know
it's
not
a
requirement
to
have
Docker
I,
don't
really
see
the
advantage.
D
I
mean
I,
guess
it
depends
at
the
end
of
the
day,
what
tools
you're
familiar
with
in
terms
of
automation,
because
that's
the
biggest
thing
here
right
I
mean
to
to
really
get
these
networks
to
to
work.
You
know
in
I
mean
to
have
large
scale
deployments.
You
really
need
to
have
automation,
infrastructures,
code,
I,
think
I
actually
had
there
are
actually
a
couple
of
projects
like
you
know,
you
haven't
looked
at
the
hyperledger
fabric
operator,
that's
a
big
one!
You
know
that's
kind
of
coming
up
this.
C
D
So
I'm
not
I,
don't
know
about
like
a
SQL
for
encryption.
That
I'm
aware
of
so
I
thought
it
was
more
meant.
You
know
how
we
equated.
You
know
couchdb,
so
couchdb
has
its
own
DSL
for
data
query,
but
as
far
as
encryption
I'm,
not
sure
you
know
what
what
solutions
would
that
would
there
be?
There
are
SQL
base
for
that,
and
in
terms
of
that
apologies
I
mean
you
can
see
what
we
have
here,
I
mean
if,
okay,
let's
put
it
this
way,
we're
not
aware
of
someone
using.
D
But
again,
it's
important
in
our
view
to
to
look
at
some
of
these
features
that
fabric
comes
with
again.
We
talked
Mutual
TLS,
you
know,
store
data,
storage
and
things
that
nature.
You
know
we
think
it's
you
know
those
have
to
be
understood
well
in
order
to
leverage
fabric,
it's
at
its
full
capacity.