Forem: Thao Nguyen

[Go Tour ] 3. Hot-reload

Thao Nguyen — Tue, 19 Dec 2023 13:57:29 +0000

1. What is Hot-reload?

Hot-reload or also known as Auto-reload, It’s like when you make a change to the source code and it automatically takes effect without a manual rebuild or restart. It helps to eliminate those repetitive and tedious tasks.. It saves and increase productivity.
The traditional technique to achieve hot-reload in Golang is to install a third-party tools or libraries libraries such as Air, Fresh, …etc. However, in this section, we will explore how to configure hot-reload without any third-party tools neither nor libraries. That will use the built-in compose watch a new feature of Docker Compose v2.22.

2. Docker Compose Watch (v2.22)

Docker Compose Watch is a new feature of Docker Compose v2.22. It allows us to watch the changes of the source code and automatically rebuild the image. It’s like a hot-reload feature for Docker Compose. It’s very useful for the local development environment. It helps to eliminate the repetitive and tedious tasks of rebuilding the image and restarting the container. It saves and increase productivity. https://docs.docker.com/compose/file-watch/

Compose Watch versus bind mounts:

Compose supports sharing a host directory inside service containers. Watch mode does not replace this functionality but exists as a companion specifically suited to developing in containers.

More importantly, watch allows for greater granularity than is practical with a bind mount. Watch rules let you ignore specific files or entire directories within the watched tree.

For example, in a JavaScript project, ignoring the node_modules/ directory has two benefits:

Performance. File trees with many small files can cause high I/O load in some configurations
Multi-platform. Compiled artifacts cannot be shared if the host OS or architecture is different to the container
For example, in a Node.js project, it's not recommended to sync the node_modules/ directory. Even though JavaScript is interpreted, npm packages can contain native code that is not portable across platforms.

3. Auto-reload using Docker Compose Watch


--- a/gotour/3.setup-hot-reload/compose.yaml
+++ b/gotour/3.setup-hot-reload/compose.yaml
@@ -1,7 +1,6 @@
 version: '3.7'

 services:
-
   basic-svc:
     build:
       context: ./basic-svc
@@ -9,6 +8,10 @@ services:
       target: ${DOCKER_BUILD_TARGET:-dev}
     ports:
     - 8080:8080
+    develop:
+      watch:
+        - action: rebuild
+          path: ./basic-svc
   basic-ui:
     build: 
       context: ./basic-ui
@@ -16,3 +19,12 @@ services:
       target: ${DOCKER_BUILD_TARGET:-dev}
     ports:
       - 3000:3000
+    develop:
+      watch:
+        - action: sync
+          path: ./basic-ui
+          target: /src
+          exclude:
+            - node_modules
+        - action: rebuild
+          path: ./basic-ui/Dockerfile
\ No newline at end of file

For the basic-svc service, we use the action: rebuild to rebuild the image when the source code changes. As outlined in the prior article, If the Dockerfile is optimized, the rebuild process should be fast.

[Go Tour ] 2. Optimize Dockerfile

Thao Nguyen ・ Dec 16

#go #docker #dockerfile #optimize

For the basic-ui service, we use the action: sync to sync the source code to the container when the source code changes (the auto-reload frontend application will be handled by the frontend framework).

4. Conclusion

There are several ways to do hot-reload in Golang. In this article, we delved into to configuring hot-reload without relying on any third-party tools neither nor libraries. This approach will keep the Dockerfile simple and clean, facilitating a streamlined development environment.

[Go Tour ] 2. Optimize Dockerfile

Thao Nguyen — Sat, 16 Dec 2023 05:27:31 +0000

Simple Dockerfile


FROM golang:1.21.3-alpine

WORKDIR /app

COPY . .

RUN go build -v -o /usr/local/bin/myapp

CMD ["myapp"]

1. Identified Issues

1.1. Image size:
The golang:1.21.3-alpine base image carries a lot of stuff that make the image unnecessarily big. Since Golang is a compiled language, having the compiler and its dependencies in the final image is redundant.
Taking a simple Hello World sample for a instance, the image size amounts to 327MB.

1.2. Security Concerns:
We cannot not entirely ensure what is up in the golang:1.21.3-alpine image.

1.3. Inefficiency:
Despite Docker's layer caching, the COPY . . instruction invalidates the cache for all the subsequent changes. Consequently, any modification will result in downloading all the dependencies and full recompilation. the simple Hello World sample image would approximately take 10 seconds to build.

```
#9 [5/5] RUN go build -v -o /usr/local/bin/myapp
#9 0.503 go: downloading gorm.io/gorm v1.25.5
#9 0.505 go: downloading gorm.io/driver/sqlite v1.5.4
#9 0.723 go: downloading github.com/mattn/go-sqlite3 v1.14.17
#9 0.913 go: downloading github.com/jinzhu/now v1.1.5
#9 0.913 go: downloading github.com/jinzhu/inflection v1.0.0
#9 1.182 internal/goos
#9 1.182 internal/itoa
#9 1.182 internal/godebugs
...
#9 8.840 gotour/example
#9 DONE 9.6s
```

2. Optimizations

2.1. Use a multi-stage build to reduce the image size and improve security.

#----- Builder stage -----#
FROM golang:1.21.3-alpine as builder

WORKDIR /app

# download dependencies
RUN --mount=type=bind,source=go.mod,target=go.mod \
    --mount=type=bind,source=go.sum,target=go.sum \
    go mod download -x

# compile go binary
RUN --mount=type=bind,source=.,target=.\
    CGO_ENABLED=0 \
    go build -o /usr/local/bin/myapp ./

#----- Runtime stage -----#
FROM gcr.io/distroless/static-debian11 as runner
COPY --from=builder /usr/local/bin/myapp /usr/local/bin/myapp
EXPOSE 8080
CMD ["myapp"]

#----- Dev stage -----#
FROM runner as dev

#----- Prod stage -----#
FROM runner as prod

First, we split the Dockerfile into two main stages: builder and runner. The builder is responsible for compiling the Go binary and the runner is responsible for running the binary. The runner uses the distroless/static-debian11 image as its base image which is a minimal image that contains only the necessary dependencies to run a statically compiled binary.
The image size is now reduced to 13.64MB.

Second, we seperate the download of dependencies and the compilation of the binary into two separate steps. Most of the time, the dependencies do not change as often as the source code. Therefore, we can only invalidate the docker layer cache when the dependencies change. This will save us a lot of time when building the image.

...
# download dependencies
RUN --mount=type=bind,source=go.mod,target=go.mod \
    --mount=type=bind,source=go.sum,target=go.sum \
    go mod download -x

# compile go binary
RUN --mount=type=bind,source=.,target=.\
    CGO_ENABLED=0 \
    go build -o /usr/local/bin/myapp ./
...

2.2. Use docker dedicated RUN cache

However, a drawback arises when changing dependencies (go.mod), as Docker tends to redownload all dependencies and recompile the binary, leading to inefficiency.
In prior article:

[Go Tour] 1. Exploring the `go build` Command

Thao Nguyen ・ Dec 12 '23

#go #explore

I introduced how go buildkit caches the downloaded dependencies and compiled binaries. To capitalize on this feature, we can utilize Docker's dedicated RUN cache. The Dockerfile is as follows:

# download dependencies
-RUN --mount=type=bind,source=go.mod,target=go.mod \
+RUN \
+   --mount=type=cache,target=/go/pkg/mod \
+   --mount=type=bind,source=go.mod,target=go.mod \
    --mount=type=bind,source=go.sum,target=go.sum \
    go mod download -x

# compile go binary
-RUN --mount=type=bind,source=.,target=.\
+RUN \
+   --mount=type=cache,target=/go/pkg/mod \
+   --mount=type=cache,target=/root/.cache/go-build \
+   --mount=type=bind,source=.,target=.\
    CGO_ENABLED=0 \
    go build -v -o /usr/local/bin/myapp ./

By adding --mount=type=cache,target=/go/pkg/mod and --mount=type=cache,target=/root/.cache/go-build to the RUN command, we can use docker dedicated RUN cache to cache the dependencies and the compiled binary. Everytimes docker BuilderKit run the RUN command, it will mount the cache to the specified target. This will leverage the artifacts from the previous build and save us a lot of time.
For instance, I made a change into go.mod and repository package and re-build the image. The output is as follows:

#9 [builder 3/4] RUN     --mount=type=cache,target=/go/pkg/mod     --mount=type=bind,source=go.mod,target=go.mod     --mount=type=bind,source=go.sum,target=go.sum     go mod download -x
#9 DONE 0.3s

#10 [builder 4/4] RUN     --mount=type=cache,target=/go/pkg/mod     --mount=type=cache,target=/root/.cache/go-build     --mount=type=bind,source=.,target=.     CGO_ENABLED=0     go build  -v -o /usr/local/bin/myapp ./
#10 0.556 gotour/example/internal/repository
#10 0.587 gotour/example/internal/service
#10 0.597 gotour/example
#10 DONE 1.0s

This log discloses that the docker BuilderKit re-executed go mod download command but it was exceptionally fast as the go mod reused the downloaded dependencies from the cache. Similarly, the go build command was also re-executed and remarkably swift, as it only recompiled three packages (repository, service and main) instead of the whole project along with all Go standard libraries.

2.3. Multi platforms build (Bonus)

We can also use docker multi platform build to build the image for different platforms. For instance, we can build the image for linux/amd64 and linux/arm64 platforms.

#----- Builder stage -----#
-FROM golang:1.21.3-alpine as builder
+FROM --platform=${BUILDPLATFORM} golang:1.21.3-alpine as builder
+ARG TARGETOS
+ARG TARGETARCH

RUN \
   --mount=type=cache,target=/go/pkg/mod \
   --mount=type=cache,target=/root/.cache/go-build \
   --mount=type=bind,source=.,target=.\
    CGO_ENABLED=0 \
+   GOOS=${TARGETOS} \
+   GOARCH=${TARGETARCH} \
    go build -v -o /app/bin/main .

3. Conclusion

In this section, we have explored how to optimize the Dockerfile for a golang application. Key takeaways include leveraging Docker's multi-stage build to diminish image size (from >300Mb to 13Mb) and enhance security. Additionally, We delved into utilizing Docker's dedicated RUN cache to speed up the build process. However, this technique is primarily effective on the Local Development Environment. For the CI/CD pipeline, we need a more advanced technique to enable the cache across separate builds.

In the upcoming section, we will delve into configuring hot-reload in local development environment for a Golang application.

Thank you for reading.

[Go Tour] 1. Exploring the `go build` Command

Thao Nguyen — Tue, 12 Dec 2023 08:59:17 +0000

First execution of `go build`

Let's start with a basic Go application

in the go build command, you can use the -v option to display the names of packages as they are compiled:
CGO_ENABLED=0 go build -v -o /tmp/basic-svc ./

$ CGO_ENABLED=0 go build -v -o /tmp/basic-svc ./
go: downloading gorm.io/gorm v1.25.5
go: downloading gorm.io/driver/sqlite v1.5.4
go: downloading github.com/mattn/go-sqlite3 v1.14.18
go: downloading github.com/jinzhu/now v1.1.5
go: downloading github.com/jinzhu/inflection v1.0.0
internal/goexperiment
internal/godebugs
internal/unsafeheader
internal/coverage/rtcov
internal/goarch
internal/goos
unicode/utf8
math/bits
internal/cpu
runtime/internal/atomic
internal/itoa
runtime/internal/syscall
internal/race
sync/atomic
unicode
encoding
unicode/utf16
internal/abi
runtime/internal/math
runtime/internal/sys
crypto/internal/alias
crypto/subtle
crypto/internal/boring/sig
strings
....

Upon the first execution of go build, some packages are downloaded from internet. And a bunch of package, including many Go standard libraries are compiled.

Caching in `go build`

The downloaded packages are stored in ~/go/pkg/mod/*, and the compiled binaries generated by go build reside in ~/.cache/go-build/*. Keeping the source code unchanged, and execute the go build command again, no packages are recompiled as it efficiently utilizes the cache.

$ CGO_ENABLED=0 go build -v ./
$ 
$

Compilation of Dependencies

In this example, the dependency hierarchy: the main imports the service, the service imports the repository.
When changes are made to the repository package, executing go build subsequently triggers recompilation of three packages:

$ CGO_ENABLED=0 go build -v -o /tmp/basic-svc ./
openlab1/basic-svc/internal/repository
openlab1/basic-svc/internal/service
openlab1/basic-svc

Key Takeaways:

Go builder detects which packages need to be re-compiled. It avoid unnecessary recompilation.
During the first execution of go build, all the necessary packages are downloaded (if they do not exist) and subsequently compiled.
This feature can be leveraged to optimize a Dockerfile specifically for a Golang application (details in the next post)
Maintaining small and independent Go packages helps prevent unnecessary recompilations. (details in the next post)

Forem: Thao Nguyen

[Go Tour ] 3. Hot-reload

1. What is Hot-reload?

2. Docker Compose Watch (v2.22)

3. Auto-reload using Docker Compose Watch

[Go Tour ] 2. Optimize Dockerfile

Thao Nguyen ・ Dec 16

4. Conclusion

[Go Tour ] 2. Optimize Dockerfile

Simple Dockerfile

1. Identified Issues

2. Optimizations

2.1. Use a multi-stage build to reduce the image size and improve security.

2.2. Use docker dedicated RUN cache

[Go Tour] 1. Exploring the `go build` Command

Thao Nguyen ・ Dec 12 '23

2.3. Multi platforms build (Bonus)

3. Conclusion

[Go Tour] 1. Exploring the `go build` Command

First execution of go build

Caching in go build

Compilation of Dependencies

Key Takeaways:

First execution of `go build`

Caching in `go build`