Containers are an amazing technology that is revolutionising how we do computing in the modern age. 5 years ago, people were starting to use Docker and realising the potential that container technology could offer. Now every major cloud provider offers a container service with the addition of container orchestrator like Kubernetes that millions of developers around the world are starting to use. Now many of our applications are running in containers why not use that magical portable configuration that containers offer to replicate our production environments locally on our laptops… enter MicroShed and the Testcontainers frameworks. Testcontainers run and test with true-to-production environments in development with minimal re-writing of your test code giving you more time as a developer to write your application. This talk will give you a great overview of the technology and will demo how simple it is to create and run a MicroShed test in Maven.
Alluxio Monthly Webinar | Cloud-Native Model Training on Distributed Data
Replicating production on your laptop using the magic of containers v2
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27. @MicroShedTest
public class MyTest {
// Search for Dockerfile.
// Start app in Container.
// Wait for Container before running tests.
@Container
public static MicroProfileApplication app
= new MicroProfileApplication()
.withAppContextRoot("/myservice");
// Inject JAX-RS REST Client
@RestClient
public static MyService mySvc;
// A test method like any other
@Test
public void testMyService() {
...
}
}
The @MicroShedTest annotation is required so
that the build knows this is a MicroShed test
The @Container annotation is required for
setting up your container to run your tests
inside
The @RESTClient annotation is needed to
give us something to test against
The @Test annotation like you would in a
normal JUnit test.
28. public class AppContainerConfig implements SharedContainerConfiguration {
@Container
public static ApplicationContainer app = new ApplicationContainer()
.withAppContextRoot("/myservice");
}
@MicroShedTest
@SharedContainerConfig(AppContainerConfig.class)
public class MySimpleTestA {
// ...
}
@MicroShedTest
@SharedContainerConfig(AppContainerConfig.class)
public class MySimpleTestB {
// ...
}
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
Unix V7 in 1979, the chroot system call was introduced, changing the root directory of a process and its children to a new location in the filesystem.
Process Containers (launched by Google in 2006) was designed for limiting, accounting and isolating resource usage (CPU, memory, disk I/O, network) of a collection of processes.
LXC (LinuX Containers) was the first, most complete implementation of Linux container manager. It was implemented in 2008 using cgroups and Linux namespaces, and it works on a single Linux kernel without requiring any patches.
It works with many different Jakarta EE and MicroProfile runtimes such as Open Liberty and provides integration with applications using Apache Kafka for messaging.