RUDSEA: recommending updates of Dockerfiles via software environment analysis

Hassan, Foyzul; Rodriguez, Rodney; Wang, Xiaoyin

doi:10.1145/3238147.3240470

Cited by 28 publications

(10 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Their results revealed two prominent workflows, based on the automated builds feature on Docker Hub or Continuous Integration services, with different trade-offs. Hassan et al [18] proposed RUDSEA, a novel approach to recommend updates of Dockerfiles to developers based on analyzing changes on software environment assumptions and their impacts. Zhang et al [19] studied Dockerfile longitudinal changes at a large scale and presented a clustering-based approach for mining Dockefile evolutionary trajectories.…”

Section: ) Studies On Docker and Dockerfilementioning

confidence: 99%

Characterizing the Occurrence of Dockerfile Smells in Open-Source Software: An Empirical Study

Zhang

Wang

et al. 2020

IEEE Access

View full text Add to dashboard Cite

Dockerfile plays an important role in the Docker-based software development process, but many Dockerfile codes are infected with smells in practice. Understanding the occurrence of Dockerfile smells in open-source software can benefit the practice of Dockerfile and enhance project maintenance. In this paper, we perform an empirical study on a large dataset of 6,334 projects to help developers gain some insights into the occurrence of Dockerfile smells, including its coverage, distribution, co-occurrence, and correlation with project characteristics. Our results show that smells are very common in Dockerfile codes and there exists co-occurrence between different types of Dockerfile smells. Further, using linear regression analysis, when controlled for various variables, we statistically identify and quantify the relationships between Dockerfile smells occurrence and project characteristics. We also provide a rich resource of implications for software practitioners.

show abstract

Section: ) Studies On Docker and Dockerfilementioning

confidence: 99%

Characterizing the Occurrence of Dockerfile Smells in Open-Source Software: An Empirical Study

Zhang

Wang

et al. 2020

IEEE Access

View full text Add to dashboard Cite

show abstract

“…Omitting actual instruction execution, BuildKit is taken as a pre-build method in the experiment. RUDSEA [11] is a language-specific approach, and it is not compared in our experiment due to the implementing workload to cover all the languages in our datasets.…”

Section: Methodsmentioning

confidence: 99%

“…Therefore, hadolint can only detect "code smells" in a Dockerfile program [10], but just a small fraction of code smells are faults. RUDSEA [11] utilizes the change of environmentrelated code scope to recommend Dockerfile updates, preventing more Dockerfile faults. However, the faults that can be avoided by RUDSEA are also a subset of real-world ones.…”

Section: Introductionmentioning

confidence: 99%

DockerMock: Pre-Build Detection of Dockerfile Faults through Mocking Instruction Execution

Li,

Bai,

et al. 2021

Preprint

View full text Add to dashboard Cite

Continuous Integration (CI) and Continuous Deployment (CD) are widely adopted in software engineering practice. In reality, the CI/CD pipeline execution is not yet reliably continuous because it is often interrupted by Docker build failures. However, the existing trial-and-error practice to detect faults is time-consuming. To timely detect Dockerfile faults, we propose a context-based pre-build analysis approach, named DockerMock, through mocking the execution of common Dockerfile instructions. A Dockerfile fault is declared when an instruction conflicts with the approximated and accumulated running context. By explicitly keeping track of whether the context is fuzzy, DockerMock strikes a good balance of detection precision and recall. We evaluated DockerMock with 53 faults in 41 Dockerfiles from open source projects on GitHub and 130 faults in 105 Dockerfiles from student course projects. On average, DockerMock detected 68.0% Dockerfile faults in these two datasets. While baseline hadolint detected 6.5%, and baseline BuildKit detected 60.5% without instruction execution. In the GitHub dataset, DockerMock reduces the number of builds to 47, outperforming that of hadolint (73) and BuildKit (74).

show abstract

“…The time spent on the potentially lengthy downloading process may be unacceptable for the container deployment. For example, in CI/CD [23] and Dev/Ops [24] scenarios, container versions can be updated frequently [25,26], and old images have to be replaced quickly by new images for security and performance. Accordingly, researchers propose remote image formats [12][13][14] that only download a small portion of data (about 6.4%-33.3%) on demand.…”

Section: Motivationmentioning

confidence: 99%

Gear: Enable Efficient Container Storage and Deployment with a New Image Format

Fan

Bian

et al. 2021

2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS)

View full text Add to dashboard Cite

Containers have been widely used in various cloud platforms as they enable agile and elastic application deployment through their process-based virtualization and layered image system. However, different layers of a container image may contain substantial duplicate and unnecessary data, which slows down its deployment due to long image downloading time and increased burden on the image registry. To accelerate the deployment and reduce the size of the registry, we propose a new image format, named Gear image, that consists of two parts: a Gear index describing the structure of the image's file system and a set of files that are required when running an application. The Gear index is represented as a single-layer image compatible with the existing deployment framework. Containers can be launched by pulling a Gear index and on demand retrieving files pointed to by the index. Furthermore, the Gear image enables a file-level sharing mechanism, which helps remove duplicate data in the registry and avoid repeated downloading of identical files by a client. We implement a prototype of the container framework, named Gear, supporting the new image format. Evaluation shows that Gear saves 54% storage capacity in the registry, speeds up container startup by up to 5×, and reduces 84% bandwidth demands.

show abstract

RUDSEA: recommending updates of Dockerfiles via software environment analysis

Cited by 28 publications

References 23 publications

Characterizing the Occurrence of Dockerfile Smells in Open-Source Software: An Empirical Study

Characterizing the Occurrence of Dockerfile Smells in Open-Source Software: An Empirical Study

DockerMock: Pre-Build Detection of Dockerfile Faults through Mocking Instruction Execution

Gear: Enable Efficient Container Storage and Deployment with a New Image Format

Contact Info

Product

Resources

About