►
Description
This is a summary of what I've been working on in the Server Runtime SEG in the last 4 months.
To learn more about server runtime:
https://about.gitlab.com/handbook/engineering/incubation/server-runtime/
To see more videos on Server Runtime:
https://www.youtube.com/watch?v=59k2b43I4oI&list=PL05JrBw4t0Kr6sicAh753uzvoPqrGZuLB&index=1
Chapters
0:00 - Introduction
0:11 - What is server runtime
0:53 - Where are we today?
2:38 - Architecture
4:43 - Demo
10:05 - Whats next
A
A
So,
let's
start
with
what
is
server
runtime
and
why
it's
important,
so
gitlab
users
want
to
build,
run
and
test
the
code
right
from
within
the
gitlab
platform.
So
our
runtime
is
aimed
at
engineering
a
performant
and
scalable
remote
development
experience
for
our
users.
We
want
to
be
able
to
release
a
product
that
complements
the
current
web
IDE
and
brings
this
complete
developer
experience
onto
the
platform
and,
when
I
say,
complete,
developer
experience.
A
So
where
are
we
today
with
this?
So
I
spent
the
last
four
months
creating
the
first
iteration
of
this.
In
these
four
months,
I've
figured
out
the
plumbing
and
the
key
components.
I
will
comprises
our
the
remote
development
experience
such
as
authentication
and
authorization,
the
ability
to
inject
Ides
how
to
run
securely
in
a
customer
on
kubernetes
cluster,
and
things
like
that.
So
some
of
the
key
features
that
have
been
delivered
are
the
ability
to
to
start
a
workspace
using
a
def
file.
A
If
you're
testing
a
service
or
a
web
application,
you
could
actually
view
what
you're
creating
and
then
the
ability
to
inject
Ides
and
run
multiple
containers
as
a
part
of
your
workspace,
so
whether
you're
on
postgres,
so
red
is
alongside
a
workspace
so
that
you
won't
be
able
to
test
database
connection.
You
can
do
that
the
validity
in
state
for
a
workspace
to
be
able
to
stop
to
restart
and
terminate
a
workspace.
And,
of
course,
my
favorite
feature,
which
is
the
ability,
run
Docker
inner
workspace?
A
So
so
you,
if
you
are
using
Docker
in
your
workflow
and
you
use
Docker
compose,
for
example,
you
can
run
Docker
compose
in
your
workspace,
using
sysbox
as
the
isolation
mechanism,
all
right
so
with
that
I
would
like
to
briefly
touch
upon
the
architecture
of
of
of
server
runtime.
Now
this
is
a
slightly
simplified
version
of
the
architecture.
A
However,
it
covers
most
of
the
key
components,
so
we,
the
whole
architect,
is
based
on
gitlab
agent
for
kubernetes,
which
provides
us
a
strong
foundation
on
how
we
can
develop
features
on
top
of
kubernetes.
So
gitlab
agent
is
actually
consists
of
two
components:
the
there's
a
server
component
called
the
gitlab
agent
server
component
or
Cass,
and
then
there's
also
the
component
that
runs
in
the
customers
clusters.
A
So
if
you
look
at
the
diagram,
what
you
don't
need
is
a
inbound
connectivity
from
gitlab
into
your
into
your
cluster,
so
you
don't
need
to
store
any
of
those
credentials
within
gitlab.
Instead,
gitlab
agent
reaches
out
to
gitlab
to
understand
what
should
be
the
state
of
the
workspace
right,
so
whether
I'm
asking
to
start
a
stop
or
or
terminate
a
workspace,
that
information
is
coming
from,
that
connection
from
gitlab
connect
from
gitlab
agent
to
gitlab
and
that's
all
outbound.
A
So
once
gitlab
agent
gets
that
information
from
gitlab
on
what
workspace
is
to
create
it
then
spins
up
those
workspaces
and
the
workspaces
are
nothing
but
port
and
kubernetes
and
containers.
Underneath
the
hood
and
essentially
what
happens
is
we
run
an
IDE
alongside
your
your?
You
know,
your
workspace,
for
example,
if
you've
got
to
go
or
no
DS
workspace
will
run
an
IDE
we'll
inject
an
IDE
into
the
workspace
and
we'll
also
add
on
top
of
that,
an
authentication
layer
so
that
only
the
right
people
can
access
a
workspace.
A
So
once
I
once
our
container
started,
we
create
other
objects
and
kubernetes
such
as
services
and
ingresses,
and
things
like
that,
so
that
users
can
actually
access
that
workspace
right.
So
users
want
to
go
on
the
on
online
and
then
right
from
the
browser
get
into
the
workspace
and
that's
what
this
enables
again.
This
is
all
based
on
the
dev
file
standard,
so
we
use
the
default
standard
and
the
defile
library
to
actually
spin
up
these
workspaces.
A
So
I
start
my
journey
from
a
repository
in
gitlab.
This
is
a
standard
node.js
repository
which
is
an
Express
app.
It
just
says
the
simple
hello
world
message
when
you
visit
the
root
so
I
can
actually
the
the
important
thing
about
this
repository
is
the
fact
that
it
has
a
def
file
or
demo,
which
defines
what
my
the
shape
of
my
environment
should
look
like,
so
I'm,
defining
a
runtime
which
is
node
and
I'm,
also
defining
that
I
need
a
post
class
database
to
store,
maybe
some
data
right.
A
So
that's
the
shape
of
my
environment.
I
can
go
ahead
and
start
a
workspace
by
clicking
on
the
open
workspace
button.
I
can
do
this
from
an
MR
or
from
a
branch
or
from
the
screen
here
so
I've
gone
ahead
and
selected.
A
ref
and
I
can
select
an
ID
to
inject
now.
I
have
some
certain
choices
here:
I
can
inject
vs
code
or
VI,
I
can
just
go
to
terminal
or
I
could
I
could
select
Jupiter
Hub?
We
can
select
multiple
Ides
or
we
could
we
could.
A
We
could
inject
multiple
IDs
in
the
future,
and
so
I
can
go
ahead
and
hit
the
create
workspace
button
to
actually
start
the
workspace
creation.
Now
what's
happening
behind
the
scenes,
is
that
gitlab
agents
picking
this
up
and
starting
to
provision
the
workspace
and
as
it
does,
that
I
see
an
update
of
the
status
as
it's
happening.
So
the
workspace
is
starting
up.
A
So
now,
if
I
hit
refresh,
it
should
start
running
in
a
bit,
so
the
workspace
is
now
running.
I
can
go
ahead
and
open
up
the
workspace,
and
the
first
thing
it
asks
me
to
do
is
authenticate.
So
this
is
where
the
authentication
and
authorization
takes
place
we
use
or
to
proxy
for
that,
and
so
the
authentication
then
authenticates
the
user
with
gitlab,
but
also
authorizes
to
make
sure
that
I'm,
the
owner
of
the
workspace
and
so
only
I,
should
have
access
to
the
workspace.
So
that's
it
so
I'm.
A
Now,
in
my
workspace
I'm
in
a
full,
full-fledged
vs
code,
IDE
I
can
go
ahead
and
open
up
my
workspaces
folder,
where
I've
got
this
example.
So
it's
it's
pre-cloned
for
me.
So
it's
already
been
cloned
and
all
the
dependencies
have
already
been
been
included.
So
if
you
see
you've
got
this
main
JS
I
mean.js
I
can
start
exploring
it.
I
have
my
Dev
file
yaml
here.
A
So
the
first
thing
I
want
to
do
is
once
I
have
access
to
my
workspace
is
I
want
to
go
ahead
and
and
start
testing
out
my
app
running
my
app
right.
So
I
can
go
ahead
and
install
my
dependencies
by
running
npm
and
because
I've
specified
the
runtime
there
in
the
dev
file.
I
have
npm
in
this
workspace,
so
that's
gone
and
install
my
dependencies.
A
I
can
go
ahead
and
say:
npm
start
to
actually
go
ahead
and
start
the
application
now,
because
in
my
def
file,
I'd
also
specified
the
fact
that
I
need
to
expose
the
bot,
so
I
can
actually
visit
this
application.
So
I
can
go
and
put
in
the
port
number
here
in
front
of
that
application
and
if
I
go
click.
A
Yes,
you
can
see
that
it
shows
me
that
hello,
world
application
right
there
I
could
actually
make
changes
to
this
application
and
see
the
changes
immediately
reflect
so
I
can
go
ahead
and
say
hello,
gitlab,
workspaces
and
as
soon
as
I
hit,
save
and
refresh
here,
you'll
see
that
it's
it
changed
the
text
right,
so
it
makes
the
development
experience
really
seamless.
Just
like
you
would
on
your
local
machine
also
because
this
runs
multiple
containers,
I'm
also
running
postgres.
A
As
a
part
of
this
workspace
I
can
actually
access
that
postgres
container
as
well.
So
here
I've
got
a
simple
DB
file
which
accesses
postgres
running
on
localhost,
and
so
just
like
I
would
on
my
local.
If
I
had
postgres
installed,
I
could
go
ahead
and
access
postcards,
so
I'm
going
to
go
ahead
and
create
a
table
called
test
and
insert
some
values
into
that
table.
A
I
can
run
some
queries
and
you
could
see
that
the
hello
world
is
returned
from
that
table
that
I
created
so
again.
I
have
access
to
multiple
dependencies.
I
can
install
postgres
and
redis,
and
things
like
that.
So
so
now
that
I'm,
ready
I
can
go
ahead
and
create
a
branch
and
commit
these
changes.
So
I
could
say
get
branch
actually
check
out
feature
one
so
I'm
creating
a
branch
here
I
can
go
ahead
and
add
my
changes
to
the
bronze
commit.
A
A
So
so
that's
the
entire
experience.
So
once
I'm
done
with
my
workspace,
I
can
go
ahead
and
actually
terminate
my
workspace
as
well,
so
I
can
go
ahead
and
click
dominate
and
that
would
actually
terminate
my
workspace.
So
that's
the
entire
process
of
how
gitlab
workspaces
could
work
okay,
so
with
that
I'd
like
to
cover
what's
next,
so
the
last
four
months
have
been
very
fruitful,
as
I've
determined,
I
think
some
of
the
most
complex
parts
of
the
architecture.
A
In
this
time
another
team,
the
remote
development
team,
has
been
formed
within
the
editor
group
and
also
have
been
investing
great
approaches
and
what
could
work
for
this?
So
what
I'll
be
doing
is
joining
forces
with
them
in
in
the
next
few
months
and
coming
together
to
determine
the
most
suitable
architecture,
firming
up
our
execution
plan
and
taking
into
fruition.
In
the
next
few
months,
what
we
want
to
be
able
to
do
is
pilot
this
with
a
select
set
of
customers,
and
that
will
be
our
priority
for
the
foreseeable
future.