November 2017 Summaries

Octopus Deploy 4.1 introduces new capabilities for managing application deployments and certificates, particularly for deploying web applications in Tomcat using artifacts from Maven repositories. The blog post outlines a demonstration of these features by deploying a demo application in Tomcat 9 on Windows 2016, integrating Maven Central as an external feed in Octopus to facilitate artifact consumption. It also covers generating and deploying a self-signed ECDSA certificate to secure the application, setting up deployment projects in Octopus, and configuring Tomcat for HTTPS using the NIO2 SSL implementation. The process includes creating a deployment project in Octopus, utilizing built-in steps to automate application and certificate deployment, and verifying the deployment result by accessing the secured demo application. The blog emphasizes Octopus's ability to streamline the deployment lifecycle with these built-in steps, highlighting its utility for automating Java application deployments.

This text describes the creation and testing of a simple Enterprise JavaBeans (EJB) application, consisting of two classes: EnterpriseJavaBean, which writes a UUID to the console asynchronously, and StartupService, which calls the EnterpriseJavaBean's method multiple times upon startup. It highlights the challenge of testing EJBs in environments that do not recognize EJB annotations, such as JUnit, where asynchronous behavior and execution nuances differ from server deployments. To address this, the text introduces Arquillian, a testing framework that enables testing of EJBs in an environment that simulates real application server conditions, thus ensuring the tests reflect actual production behavior. The use of Arquillian allows for accurate testing by deploying Java artifacts using the ShrinkWrap library and running tests that behave consistently with server deployments, overcoming the limitations of traditional unit testing for EJBs.

The blog post by Matthew Casperson explores the use of Arquillian for infrastructure testing, highlighting its capability to manage multiple Java application server configurations, including WildFly, Red Hat JBoss EAP, and Tomcat, among others. The author explains how Arquillian, combined with the Octopus tool, facilitates testing across various server environments by integrating with unit test libraries like JUnit and running tests directly from Maven. The post details the configuration process required in the Maven POM file and highlights the use of Arquillian Chameleon to manage different containers, demonstrating how to set up profiles for specific server versions like Tomcat 8 and WildFly 9. The testing approach is exemplified through a simple HTTP GET request to verify server functionality, emphasizing the benefit of testing code as a client to the application servers rather than deploying code within them. The article concludes by underscoring the efficiency of using Arquillian for testing diverse application server versions, enhancing the integration between Octopus and Java application servers.

Tomcat 8.5+ enhances its support for secure networking by allowing multiple certificate types for each host, accommodating both RSA and ECDSA certificates to cater to a range of browser compatibility. This feature is particularly advantageous for supporting older browsers with RSA and newer, compatible browsers with ECDSA. The blog post provides a detailed guide on generating self-signed RSA and ECDSA keys using OpenSSL commands, configuring Tomcat with these certificates by adding multiple `<Certificate>` elements to a `<SSLHostConfig>` element in the `server.xml` configuration file, and verifying the setup with an online service. This dual certificate support ensures a broad client reach while maintaining security, and the post concludes with a mention of Octopus Deploy for automating Java application deployments.

Octopus Deploy 4.0 introduces a revamped user interface and enhanced user experience, transitioning from Angular 1.4 to React and Redux to improve usability and scalability. The update emphasizes ease of use, incorporating Google's material design guidelines and offering features like filters, search controls, and consistent actions to streamline navigation and management of projects. The deployment release page has been simplified for easier customization, and the infrastructure page has been redesigned to better accommodate large-scale environments. Additionally, the release includes several breaking changes and performance optimizations, such as limiting simultaneous deployments to 10 targets by default and refining API functionalities, while also requiring certain post-install data fixes during the upgrade process.

Server Name Indication (SNI) in Tomcat 8.5 and 9 allows the server to use multiple SSL certificates on a single HTTPS port by mapping them to the hostname of incoming requests. This blog post guides users through configuring SNI in Tomcat 9 by creating self-signed certificates for different companies and configuring the Tomcat server to respond with the appropriate certificate based on the hostname. The configuration process involves modifying the server.xml file to include a <Connector> element that references the certificates, setting a default SSL host, and using the Apache Portable Runtime for improved performance. By testing the setup through a hosts file modification, users can verify that Tomcat correctly assigns certificates based on the requested hostname, demonstrating SNI's capability to manage multiple certificates and provide secure connections for various domains.

The blog post by Matthew Casperson explores the process of configuring a cluster of WildFly instances in an AWS environment by extending the use of a WildFly domain. The author distinguishes between a domain, which is a management tool, and a cluster, which allows sharing of Servlet session state across multiple WildFly instances. The configuration utilizes an Aurora MySQL-compatible database for cluster node discovery and involves setting up a JGroups stack with TCP and JDBC_PING protocols to replace the default UDP and multicasting, which are not supported by AWS. The article also discusses the necessity of a centralized load balancer for distributing web requests evenly across cluster nodes, ensuring session persistence even if one node fails. Additionally, the author provides steps for deploying a distributable web application and verifying the cluster configuration by checking session data replication across nodes, highlighting the importance of session continuity in a clustered environment.

Configuring a WildFly domain in a cloud environment like AWS can be challenging due to the absence of fixed IP addresses and network broadcasts for resource discovery. A practical solution for AWS users is leveraging an S3 bucket as a centralized configuration point to discover domain controllers. This process involves creating an IAM user with specific permissions to access the S3 bucket, setting up the bucket, and configuring the domain controller to update its details in the bucket. A management user, such as a 'slave', is created to allow slave instances to connect to the domain controller. The domain controller's management port must be bound to an external interface, and the slave instance needs to be configured with the appropriate server identities and discovery options. Once configured, the management console can be used to verify the successful connection between the master and slave hosts. This approach simplifies the configuration process by eliminating the need for fixed IP addresses and works around AWS's network broadcast limitations.

Octopus Deploy 4.0 introduces significant improvements to its configuration management, primarily by allowing reading and writing of configurations through a new API, which streamlines both development and deployment processes for users. This update addresses the challenges faced by users responsible for provisioning and maintaining the Octopus server, such as the complexity of managing numerous configuration options and the requirement for console access to modify settings. The API enables more intuitive configuration management by using structured JSON documents for configurations, enhancing the user interface, and supporting extensions through dynamically generated forms. While node-specific settings in a high-availability setup remain unchanged and require a service restart, the API facilitates immediate cache updates on single nodes and staggered updates across multiple nodes. These enhancements aim to simplify configuration management and improve the overall user experience, with ongoing feedback welcomed to refine the system further.

Matthew Casperson's blog post from November 2017 provides a step-by-step guide on setting up a basic Jenkins instance on Ubuntu 17.10, highlighting Jenkins as a leading continuous integration (CI) system from the 2017 JetBrains developer ecosystem survey. The guide begins with installing essential Linux tools, followed by the installation and initial configuration of Jenkins, including setting up an admin user and suggested plugins. It further explains installing additional plugins necessary for building a Maven project and deploying it with Octopus, applying a custom Jenkins theme, and configuring essential tools like Java, Maven, and the Octopus CLI. The post concludes by indicating the readiness for building and deploying a Java application in future posts, encouraging readers interested in automating Java application deployment to try Octopus Deploy.

Matthew Casperson's blog post from November 11, 2017, outlines the process of using Jenkins Pipelines to automate the deployment of a Java web application to a Tomcat server using Octopus Deploy. The post demonstrates how to create a Jenkinsfile to build a WAR file with Maven, push it to Octopus, and deploy it to Tomcat, highlighting the integration of Jenkins and Octopus for seamless deployment. It explains the creation of a new Octopus project, the use of an API key stored securely in Jenkins, and the execution of commands using the Octo CLI tool. The article emphasizes the efficiency of Jenkins Pipelines in managing build processes and the ease of incorporating Octopus for deployment automation, encouraging readers to explore Octopus Deploy for automating Java application deployments.

In the Octopus 4.0 update, the development team transitioned from using Angular to React for the frontend, driven by the need to manage an expanding codebase and improve performance. Initially built with Angular 1.2, the old system couldn't efficiently handle the increasing functionality and developer count, leading to a bloated and inconsistent architecture. The shift to React, facilitated by its Virtual DOM, significantly improved rendering times and scalability, particularly for users dealing with large datasets. The move also involved adopting TypeScript to enhance code reliability and maintainability, addressing issues that arose with JavaScript's dynamic typing. The decision to use React was influenced by its strong community support and potential for building native and server-side applications, although the team chose to use Redux selectively to manage state only in necessary parts of the application. This comprehensive overhaul aimed to provide a more robust and efficient platform, reflecting lessons learned from the evolving needs of both developers and users.

When automating WildFly server builds using tools like Puppet, Chef, or Ansible, customization of configuration files such as standalone.xml, domain.xml, host.xml, and host-slave.xml is crucial. Two primary methods exist: directly editing these XML files or utilizing the WildFly CLI. Direct XML editing is straightforward and does not require a running WildFly instance, but it risks overwriting runtime changes and complicates version upgrades. In contrast, the CLI approach, although more complex and requiring a running instance, offers idempotency and ease of upgrade across WildFly versions. CLI scripts allow targeted changes with immediate error feedback and can be adapted for complex environments using Java libraries. Despite each method's benefits and drawbacks, the choice depends on the specific requirements for idempotency and ease of use, with CLI scripts favored for idempotency and XML editing for simplicity.

Octopus Deploy 4.0 has introduced a revamped Deploy Release page, enhancing the deployment process to multiple environments or tenants with a new design that divides the page into two sections, North and South. The North section allows users to select environments and tenants, configure options for all deployments, and access advanced settings such as scheduling and step exclusion. The South section provides a clearer display of deployments to be created, particularly important for complex tenant-tag expressions, and offers options for previewing and customizing deployment steps. A significant improvement is the addition of a "Retry Unsuccessful" button, allowing users to re-attempt failed deployments without reconfiguring successfully created ones. Feedback is encouraged to ensure the new design addresses previous issues effectively.

A Hollow JAR is a flexible and efficient deployment solution for Java applications that combines elements of both UberJARs and traditional application servers. Unlike an UberJAR, which contains both the application code and the code required to launch an application, a Hollow JAR only includes the latter, with the application code residing in a separate WAR file. This separation allows for frequent updates to the WAR file without altering the JAR, which can be advantageous in environments using layered container images or AWS autoscaling groups. The process of creating a Hollow JAR involves tools like SwarmTool, which facilitates the migration of existing applications to platforms like WildFly Swarm without significant modifications to the build process. This approach is demonstrated through the Ticket Monster demo application, where specific dependencies are adjusted to accommodate Java 9 and ensure compatibility with the Swarm platform. Hollow JARs offer deployment flexibility similar to UberJARs but with added efficiency in update management, making them a valuable option for automating Java application deployments.

Java web application deployment has evolved from using traditional Java EE application servers like WildFly, which host multiple applications and provide management tools, to using self-contained UberJARs, which bundle all necessary classes and resources into a single executable JAR file. This shift is influenced by modern paradigms such as microservices and Platform as a Service (PaaS), where UberJARs offer ease of distribution and scalability, requiring only a Java Runtime Environment (JRE) to run. WildFly Swarm facilitates this transition by allowing Java EE applications to be packaged as UberJARs, combining the benefits of application servers with the flexibility of standalone executables. While application servers offer centralized management and shared resources, UberJARs move infrastructure management to build tools and are favored in environments prioritizing agility and simplicity.

Octopus Deploy 4.0 introduces significant improvements aimed at addressing the challenges faced by users with numerous deployment targets. The update focuses on enhancing the rendering time of environments and deployment targets, and introduces new search and filtering capabilities to improve usability and scalability. The infrastructure has been reorganized with a new Infrastructure Overview and separate screens for Environments and Deployment Targets, allowing users to access information quickly and efficiently. These changes are designed to accommodate both large-scale operations with thousands of deployment targets and smaller setups, ensuring that users can manage deployment targets effectively without unnecessary delays or complications. The update also includes client-side caching and paging support to further streamline the process, making it easier for users to find and interact with their deployment targets.