2018-03-29 20:29:08 +02:00
|
|
|
Alpine Linux 3.7+
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
=========================================================
|
|
|
|
|
|
|
|
|
|
For building Alpine Linux dev packages, we use docker.
|
|
|
|
|
|
|
|
|
|
Install docker 17.05 or later
|
|
|
|
|
-----------------------------
|
|
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
Depending on your host, there are different ways of installing docker. Refer
|
|
|
|
|
to the documentation here for instructions on how to install a free version of
|
|
|
|
|
docker: https://www.docker.com/community-edition
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
|
|
|
|
Work with sources
|
|
|
|
|
-----------------
|
|
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
::
|
|
|
|
|
|
|
|
|
|
git clone https://github.com/frrouting/frr.git frr
|
|
|
|
|
cd frr
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
|
|
|
|
Build apk packages
|
|
|
|
|
------------------
|
|
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
::
|
|
|
|
|
|
|
|
|
|
./docker/alpine/build.sh
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
|
|
|
|
This will put the apk packages in:
|
|
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
::
|
|
|
|
|
|
|
|
|
|
./docker/pkgs/apk/x86_64/
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
|
|
|
|
Usage
|
|
|
|
|
-----
|
|
|
|
|
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
To create a base image with the frr packages installed:
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
::
|
|
|
|
|
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
docker build --rm -f docker/alpine/Dockerfile -t frr:latest .
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
Or, if you don't have a git checkout of the sources, you can build a base
|
|
|
|
|
image directly off the github account:
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
::
|
|
|
|
|
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
docker build --rm -f docker/alpine/Dockerfile -t frr:latest \
|
|
|
|
|
https://github.com/frrouting/frr.git
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
And to run the image:
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
2018-03-20 15:43:21 +01:00
|
|
|
::
|
|
|
|
|
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
docker run -it --rm frr:latest /bin/sh
|
docker build: build Alpine Linux dev packages in docker
Building alpine packages in a "standard" distro can be
complicated due to the limited scope of the distro (embedded
and small docker images). Building in a VM is one possibility,
but docker support for alpine is very good (default docker images
come in alpine due to the very small size).
Here, we want to package up the current git repo into apk packages
that can be easily installed in alpine linux using the apk tool.
This support is not intended to package released versions of
apk packages, that, if it comes to be, should be done here:
git://git.alpinelinux.org/aports
We're content here to build packages that can be used by developers
to try out frr in docker and other alpine environments.
This is a very minimal environment, we don't support importing
keys (so, installing the packages with apk requires the
--allow-untrusted option). In addition, we can't use the
git commit id in hex as version tag, as alpine doesn't support hex
digits in the version string. So, we need to convert the git hash
to decimal before tagging the package with the extra version.
This is yucky, but I can't think of another way to get a
unique version per package. The alpine way (using a numeric date),
only works for released packages, not for dev packages.
Issue: https://github.com/FRRouting/frr/issues/1859
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-03-12 20:24:26 +01:00
|
|
|
|
|
|
|
|
Currently, we only package the raw daemons and example files, so, you'll
|
|
|
|
|
need to run the daemons by hand (or, better, orchestrate in the Dockerfile).
|
alpine packaging: build packages and base image directly from git
Currently, we tar up the git repo before building alpine packages.
This ensures that the packages we're building are exactly what is
checked in. But, in practice, this restriction causes us to not
be able to build off of git contexts, which is a convenient feature
especially when using docker-compose.
So, here, we build the alpine packages directly from the contents
of the current directory and we install the packages into a base
image to ease downstream consumption. There is still work to be
done in that area, as we need to package up the daemons, frr user
and all the rest, but that's for later...
Testing-done:
Built directly from the git repo, built from a reference to the
git repo and built using docker-compose, all seemed to work. Also,
tested by @leleobhz and seems to build fine.
Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for
the original idea for a fix.
Issue: https://github.com/FRRouting/frr/issues/2024
Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
2018-04-04 04:15:11 +02:00
|
|
|
|
|
|
|
|
We can also build directly from docker-compose, with a docker-compose.yml file
|
|
|
|
|
like this one:
|
|
|
|
|
|
|
|
|
|
::
|
|
|
|
|
|
|
|
|
|
version: '2.2'
|
|
|
|
|
|
|
|
|
|
services:
|
|
|
|
|
frr:
|
|
|
|
|
build:
|
|
|
|
|
context: https://github.com/frrouting/frr.git
|
|
|
|
|
dockerfile: docker/alpine/Dockerfile
|