►
From YouTube: Integrating GitLab with AWS - Why and How
Description
GitLab can integrate directly with AWS at many different points in your CI / CD process. This video details the value GitLab brings to AWS infrastructure and discusses the ways to integrate.
A
Hello,
my
name
is
darwin
sonoy,
I'm
a
staff
solutions
architect
in
gitlab's
alliance
partners
team.
I
wanted
to
talk
to
you
a
little
bit
about
integrating
git
lab
with
aws,
specifically
we're
going
to
go
through
a
little
bit
about
why
you
might
want
to
do
this
and
about
the
many
ways
that
you
can
go
about
actually
doing
the
integration.
A
So,
let's
dive
right
in
so
I
want
to
talk
through
just
a
couple
things
about
get
that
value
added
we're
going
to
be
diving
into
more
technical
details
about
how
to
integrate
git
lab
and
some
of
the
benefits
of
doing
so.
But
there's
some
vast
areas
of
the
product
that
are
would
be
really
hard
to
cover
in
a
short
period
of
time.
So
I
just
want
to
emphasize
those
characteristics
that
are
value
added.
So
one
of
the
first
things
to
know
is
that
it
has
industry
leading
code
change
controls
with
collaboration.
A
A
In
addition,
dynamic
review
environments
and
applications
per
feature
branch.
So,
when
you
deploy
gitlab
in
certain
ways,
especially
if
you're
using
kubernetes,
but
also
if
you're,
using
nginx
or
other
web
servers,
every
developer
feature
branch
can
have
its
own
review
environment
associated
and
every
time
the
developer
pushes
commits
that
review
environment
is
updated.
So
this
is
an
important
differentiator.
A
It's
also
important
to
understand
that
that
means
that
ci
is
not
waiting
for
merge
approvals
on
feature
branches.
It
just
goes
ahead
and
runs
every
time.
A
third
one.
That's
really
important
is
shifting
security,
hard
left,
and
what
this
means
is
that
developers
see
vulnerabilities
as
just
another,
build
bug
at
build
time
when
they're
going
through
and
running
their
builds,
instead
of
having
all
their
work
done
and
then
doing
security
scanning
and
disturbing
a
lot
of
integration,
work
and
solution
work,
that's
been
done
instead,
the
very
first
time
they
run
a
build.
A
If
there's
findings
that
are
relevant,
that
they
have
just
introduced.
Those
are
presented
to
them
immediately,
and
so
this
is
a
huge
benefit,
is
getting
the
security
story
to
be
as
far
left
as
it
possibly
can
be.
Then
advanced
deployment
controls
with
change,
set
collaboration,
so
you'll
notice,
the
collaboration
theme
comes
up
again
and
again.
A
It
also
comes
forward
to
deployment
controls
so
get
lab
embraces,
get
ops,
which
means
using
your
source,
control
management
systems,
controls
and
the
concept
of
merging
to
control,
moving
to
new
environments
and
promoting
between
environments.
So
all
of
the
collaboration
that
might
happen
in
an
operational
type
situation
with
deployment
can
also
happen.
Around
merge,
requests
and
issues
like
it
does
for
the
rest
of
our
code
and
then
finally
devops
transformation,
enablement
through
templating
and
auto
devops.
A
In
addition,
we
can
also
support
kubernetes
very
strongly
through
this
auto
devops
is
oriented
towards
kubernetes,
but
even
if
you
have
your
own
way
of
doing,
kubernetes,
then
that
cloud
native
transformation
can
also
be
facilitated
by
gitlab.
Gitlab
is
very
comfortable
with
kubernetes
even
lets
you
create
eks
clusters
in
the
ui
and
another
one
is
development,
devops
value
stream
analytics.
A
So
we're
going
to
walk
through
some
details
about
the
controls
that
we
have
in
gitlab
for
gating
controls
and
git
ops.
In
addition,
collaboration.
We
won't
actually
touch
that
deeply
on
collaboration
as
we
go
through
this,
but
all
the
collaborative
capabilities
of
gitlab
itself
are
also
in
view
here.
A
We
typically
think
of
grabbing
a
branch
to
start
our
development
activities
on
as
an
individual
developer.
Then,
as
we
bring
that
branch
into
the
shared
system,
we
are
going
to
merge
it
into
some
sort
of
shared
branch.
Now
gitlab
has
a
lot
of
controls
right
at
that
point.
As
far
as
your
code,
what
can
be
allowed
in
the
push
rules
are
one
of
those
specific
controls
and
push
rules
prevent
a
lot
of
bad
things
from
getting
pushed
to
the
main
repository.
A
We
also
have
something
called
locked
files
and
directories
which
allows
individual
developers
to
say
no
one
else
is
allowed
to
work
on
this
file
or
this
directory
on
any
other
branch.
While
I'm
working
on
it
from
your
feature
branch,
we
also
do
ci.
So
this
is
a
unique
thing
about
git
lab
git
lab
allows
you
to
do
ci
on
ephemeral,
dynamic,
developer
branches.
So
when
a
developer
creates
a
branch,
unless
you
otherwise
specify
gitlab
is
going
to
run
ci
on
that
automatically.
A
When
you
run
ci,
you
can
also
run
cd
and
another
interesting
part
of
gitlab
is
that
we
have
something
called
dynamic
review
environments
and
what
that
allows
you
to
do
is
even
on
this
developer
branch
set
up
an
environment
for
your
application
and
you
can
do
all
kinds
of
interesting
things
with
it.
After
that,
you
can
do
your
typical
user-oriented
human
testing,
but
we
can
also
do
all
kinds
of
scanning
and
testing,
including
fast
testing.
A
Also
in
the
ci
cd,
we
will
run
the
security
testing
on
every
developer
branch.
Every
time
commits
are
pushed
then,
as
we
move
to
integrate
our
code
into
this
shared
branch,
we
have
some
controls.
First
of
all,
code
review.
There
are
a
ton
of
code
review
type
controls,
I'm
not
even
touching
on
all
of
them
here,
but
branch
protections
and
tag
protections
are
examples
of
some
of
the
capabilities
that
we
can
control.
At
that
point,
we
also
have
merge
approvals,
and
this
is
a
very
rich
featured
thing.
A
A
A
We
then,
of
course,
can
do
ci
cd
on
these
shared
branches,
and
now
we
can
get
a
little
more
in
depth,
because
we
understand
that
this
is
where
we
start
to
see.
The
system
coming
together.
Maybe
5,
10,
20
100
feature
branches
are
coming
together
depending
on
the
next
release
and
what
it's
going
to
contain,
and
so
we
can
run
ci
cd
to
make
sure
that
the
software
builds
properly
deploys
properly
and
that
there's
no
security
problems
that
are
caused
by
unforeseen
merging
of
branches,
creating
actual
security
issues.
A
Gitlab
uses
it
in
a
lot
of
its
automatic
functionality,
such
as
autodevops,
but
you
can
tap
into
the
environment's
metaphor
throughout
the
entire
system
and
create
environments
in
almost
any
target
deployment
architecture
that
you
want
to
next
we're
going
to
make
a
move
to
merge
this
code
forward
so
because
git
lab
works
in
git
ops.
We
now
use
git
based
controls
to
do
our
operational
management
in
terms
of
change
management,
as
well
as
actual
deployment
of
software.
A
So,
instead
of
now,
at
this
point
handing
off
to
deployment
system,
we
merge
forward
to
a
new
branch
with
git
lab.
You
have
merge
approval,
gates
and
branch
protections
that
are
branch
specific.
This
means
that
those
are
these
particular
items
are
not
the
same
for
the
entire
repository.
It's
branch
specific.
A
You
can
see
that
we
are
also
doing
our
ci
cd
here,
but
now
I'm
depicting
that
we
can
deploy
two
amazon
type
application.
Architectures
there's
a
variety
of
ways
of
doing
this.
Some
are
supported.
Very
natively
such
as
amplify
amplify
is
one
of
the
newer
amazon
application
architectures,
and
so
it
has
built-in
capability
to
link
up
to
gitlab
for
deploy.
A
We
can
also
hand
off
to
other
intermediaries,
such
as
code
deploy,
and
we
also
have
native
kubernetes
capability
built
into
gitlab.
If
we
don't
have
quite
the
one
that
you
use,
you
can
easily
craft
something
to
link
this
up.
This
same
approach
will
then
be
repeated
throughout
additional
environments.
So,
as
we
promote
between
environments,
we
merge
to
branches
those
branches
target,
the
final
employment
environment
and
we're
able
to
have
very
granular
controls
over
who
can
deploy
where.
A
I
also
want
to
note
it's
very
common
for
many
of
our
customers
to
use
terraform
to
deploy
to
amazon,
and
we
do
have
support
for
terraform
in
two
ways.
There's
integrated
support,
so
gitlab
can
be
a
state
store,
terraform
can
run
inside
of
containers
and
in
some
ways
gitlab
gives
you
some
of
the
advantages
of
a
terraform
type
service
or
you
could
potentially
be
integrating
with
a
terraform
enterprise.
If
you
have
either
stood
that
up
or
purchased
it
as
a
service,
so
many
ways
to
consume,
terraform
and
all
of
its
cloud
benefits.
A
It's
important
to
know
that
these
pipelines
are
per
branch,
so
they
are
set
up
on
each
branch
you
want
to
deploy
to
so
the
dynamic
review
environment's
capability
is
a
little
harder
to
try
to
recreate
in
inside
of
this.
In
addition,
there's
a
lot
of
pipeline
components.
If
you
see
across
the
top
of
the
screen,
the
s3
cloud
watch
confirmation-
I
am
a
lot
of
these
elements
are
not
automatically
created
by
source
files
that
are
inside
of
a
repository.
A
A
So
this
is
the
typical
flow
notice
that
some
folks
are
not
aware
that
code
pipeline
can
be
triggered
by
an
s3
artifact
arriving,
so
it
can
monitor
s3
to
see
if
an
artifact
arrives
and
then,
if
an
artifact
arrives,
to
take
to
go
ahead
and
start
processing
a
pipeline,
also
the
elastic
container
registry.
So
we
can,
upon
the
push
of
a
new
container
to
a
certain
registry,
kickoff
code
pipeline
and
then
code
commit,
can
kick
off
a
code
pipeline
now.
One
thing
we're
going
to
cover
here
is
a
lot
of
folks.
Ask
us!
Well,
hey!
A
I
see
that
when
I
fire
up
code
pipeline,
I
can
integrate
with
code,
commit
and
a
couple
other
third-party
scm
tools,
but
I
don't
see
gitlab
there,
and
so
one
thing
we'll
talk
about
is:
if
you
do
need
to
have
code
pipeline
in
place.
How
do
you
get
into
the
front
end
of
that
funnel,
but
we'll
also
talk
about
other
ways
to
get
into
this
funnel
and
some
ways
to
move
more
towards
a
gitlab
native
environment.
A
So,
let's
look
at
adding
gitlab
to
the
mix
here
now.
Gitlab
is
a
full
sdlc
devops
tool
that
allows
you
to
manage
everything
from
agile
work
management,
all
the
way
through
to
production
and
deployment
monitoring,
and
also
defending
or
security.
When
we
have
gitlab
source
code
management
and
we
commit
code
to
it,
we
generally
go
through
a
merge
request
to
go
to
any
branch
other
than
a
feature:
development
branch
and
from
there
it
proceeds
into
gitlab
ci.
Now,
when
we
have
a
feature
branch,
the
developer
is
working
on
by
themselves.
A
A
In
any
case,
we
go
through
the
gitlab
ci
job
stream,
which
is
controlled
by
the
gitlab
ci
yaml
file,
and
this
file
is
notably
pipeline
as
code,
which
means
that
it
is
developers
changing
that
code.
Right
inside
of
that
file
is
what
controls
all
of
the
pipeline
notice
that
we
can
process
multiple
branches
in
here
now
by
default,
every
branch
would
go
through
all
jobs.
Every
time
unless
otherwise
specified
in
this
case,
we
can
handle
multiple
branches
by
having
different
jobs.
So
you
might
have
one
job.
A
Gitlab
then
also
can
deploy
these
dynamic
review
environments.
Dynamic,
review
environments
are
their
own
kind
of
feature,
but
they
also
go
along
with
security
scanning
for
dast
scanning
now.
Security
scanning
is
also
its
own
feature
for
all
the
non-dast
scanning.
You
can
do
that
scanning
without
the
dynamic
review
environments,
but
for
dast
and
for
fuzz
we
need
an
actual
standing
instance
of
the
application
and
that's
where
dynamic
review
environments
come
in.
These
dynamic
review.
A
Environments
are
also
set
up
on
every
developer,
feature
branch
so
that
they
are
automatically
available
and
they're
automatically
deployed
as
well
seamlessly
when
the
developer
creates
a
new
feature
branch
and
starts
working
on
it,
that
capability,
dynamic
review
environments
and
the
scan
security
scanning.
That
requires
an
actual
running
instance
of
the
application
kind
of
go
together.
A
Then,
from
this
we
can
start
adding
additional
triggers
to
our
gitlab
ci
jobs.
So
we
can
deposit
s3
artifacts,
which
is
a
trigger
for
code
pipeline.
We
can
also
push
containers
to
ecr,
which
is
also
a
trigger
for
code
pipeline.
So
sometimes,
when
folks
are
asking
this
question,
how
do
I
integrate
with
code
pipeline
they're?
A
Another
way,
though,
that
is
now
in
our
documentation,
but
has
not
been
in
the
past,
is
repository
push
mirroring
so
for
get
lab
premium
and
higher
you
can
configure
push
mirroring
which
allows
you
to
say:
hey
anytime.
I
get
commits
to
this
gitlab
repository
push
them
forward
into
code
commit.
So
this
is
another
method
of
integration,
in
this
case
maybe
you're
using
the
gitlab
ci
capability
just
for
dynamic
review
environments,
but
when
it's
time
to
push
to
that
next
production
branch,
well,
then
you're
going
to
send
it
straight
to
code
pipeline.
A
Another
way,
though,
is
to
have
git
lab
directly
integrated
to
deploy.
So
you
want
to
take
a
look
at
your
code
pipeline
and
understand
if
the
steps
you
have
in
there
are
actually
essential
to
getting
the
deployment
piece
done
so
code.
Build
typically
will
build
your
code
and
then
deploy
it,
but
it's
very
likely
that
there's
some
overlap
in
terms
of
what
builds
could
be
done
within
git
lab
and
then
take
advantage
of
some
of
the
advantages
that
we've
been
talking
about.
A
A
In
addition,
there
are
many
ways
to
use
terraform
inside
of
git
lab,
so
one
way
is
completely
integrated.
Git
lab
has
its
own
terraform
state
store
capabilities,
and
so
you
can
use
the
local
terraform
cli
within
a
git
lab
container.
In
order
to
do
those
deployments
in
store
state
in
git
lab,
you
can
also
obviously
integrate
it
with
terraform
enterprise,
whether
you
have
an
on-prem
or
a
sas
subscription
code.
A
So
some
of
the
significant
and
unique
capabilities,
the
velocity
of
feature
development,
especially
with
devsecops,
so
getting
that
capability
of
being
able
to
add
new
pipelines.
New
branches,
dynamic,
builds
for
all
branches,
build
this
code
or
what
I've
been
calling
pipeline
is
code
kind
of
more
self-service
for
developers.
They
can
change
that
file.
A
We
also
discussed
briefly
how
pipeline
development
becomes
just
another
developer
activity.
So
a
developer
will
create
a
new
branch
and
only
be
dealing
with
how
to
fix
the
ci
or
enhance
it
for
future
needs.
And
so
pipeline
is
code
is
not
a
small
thing
and
it
shouldn't
be
overlooked
when
you're,
considering
what
what
to
do.