For open source licenses, license compatibility only matters when we are integrating multiple components into a single program. For example, when linking a library with a program, or copying a code snippet into our code.
Docker is typically used as a separate tool without integrating code from Docker into your software. As long as it's a separate program, the license doesn't really matter.
(There are interesting considerations for the licensing of the software within a Docker image though – each image is essentially half of a Linux distro, with lots of separate programs under lots of different licenses, possibly distributed across multiple image layers.)
If you were to combine code in a manner that would create a derivative work in the sense of copyright law, then we need to think about license compatibility. While Apache-2.0 generally has pretty good compatibility, it is incompatible with GPL-2.0. The two licenses have patent-related clauses that contradict each other, so it's not possible to combine them. Sometimes, the GPL code is actually licensed under GPL-2.0-or-later, in which case choosing the GPL-3.0 license resolves the incompatibility.
At the start of this answer, I restricted the response to “open source licenses”. This is important because there are popular non-open-source licenses that can lead to licensing issues even for separate programs. Notably, the SSPL (used by MongoDB, Elasticsearch, and others) can affect your entire software stack in some scenarios. If those scenarios apply, it's typically impossible to satisfy all licenses. The CC-BY-SA-NC license is another popular non-open-source license that is highly incompatible, but at least it doesn't have an absurdly broad scope like the SSPL.