- [Instructor] In addition to exposing ports
and connecting containers together with virtual networks,
Docker also has a legacy, older way,
of linking containers together.
It's used kind of like the private network scenario,
but links are only one way.
So you can connect from all ports on one machine
to all the ports on the other,
but not in the other direction,
it gives no information the other way.
Also, secrets on the machine being linked to, say,
environment variables with database passwords,
are visible to any machine that later comes along
and decides to link to it, however, the reverse is not true.
The server can't see environment variables
on the machine's that choose to link to it.
Also, this makes things depend on startup order;
which machine is running in order
for the other one to connect to it.
It just makes orchestrating things a lot harder,
and restarting containers can be made to not break things,
if you are very careful.
If you do it just right, it can be used correctly.
I recommend sticking with the more modern options,
though there are cases where you really want the features
this offers, so let's give a quick tour.
All right, I'm going to startup a server,
it'll be a variation on our catserver
from previous examples.
We'll have, docker run --rm -ti, the usual,
and give it the name catserver,
and right in here, hmm, let's give it a secret to keep.
I'm going to give it an environment variable named SECRET.
This doesn't turn the environment variable
into some special kind,
it's just an environment variable named SECRET
to illustrate the point,
and let's call it, theinternetlovescats,
and then, --name catserver, as we had before,
running bash, and start it up.
Okay, so the catserver is running.
Now, let's connect to it.
And again, with a variation on our previous example,
we have our dogserver here, docker run --rm and ti,
- -name dogserver, but we want this dogserver
to be able to connect to the catserver.
So right in here, I'm going to add,
- -link catserver, and then run it.
Okay, so over here, I'll run a quick server,
nc -lp, port, oh how 'about 1234, highly creative,
and over here, nc, and I'm going to connect to catserver
on port 1234, woof, and there it goes.
They can reply, meow.
Let's try it the other way.
If I exit that, clear both screens,
over here on the dogserver,
I'm going to run, nc -lp, and port 4321.
Over here, nc dogserver, port 4321,
and it just says, who's dogserver,
'cause links run only one way.
Okay, now let's look at the secrets aspect.
Over here, on catserver, if I run env,
I see, apart from a bunch of terminal color settings
that will be different for everybody,
at the top, somewhere you'll find
the variable we set when we started it,
SECRET=theinternetlovescats.
Okay, now, if I run that same command over here, env,
I see that that environment variable
has been copied on to the machine that linked to it.
Under the name catserver, to tell you which container
it was copied from, env, just says it was copied
from an environment variable,
and the name of the environment variable
on that other container,
and then the secret contents,
but we don't see environment variables
from dogserver on catserver.
Again, legacy linking, only operates in one direction.
It is useful in some cases,
and you'll encounter it in a great many existing products,
and you can go ahead and use it there.
There exists a very old form of linking
that just sets IP addresses in environment variables
corresponding on both sides of the link.
This one is basically, totally unused,
and you should probably avoid it in cases
where it still turns up.