Building a Docker image mainly means creating a Dockefile and specifying all the required components to install and configure.
So a Dockerfile contains at least many operating system commands for installing and configuring software and packages.
Keeping all commands in one file (Dockerfile) can lead to a confusing structure.
In this post I describe and explain an extensible structure for a Docker project so that you can reuse components for other components.
General Structure
The basic idea behind the structure is: split all installation instructions into separate installation scripts and call them individually in the dockerfile.
In the end the structure will look something like this (with some additional collaborators to be added and described later)
RUN bash /tmp/${SCRIPT_UBUNTU}
RUN bash /tmp/${SCRIPT_ADD_USER}
RUN bash /tmp/${SCRIPT_NODEJS}
RUN bash /tmp/${SCRIPT_JULIA}
RUN bash /tmp/${SCRIPT_ANACONDA}
RUN cat ${SCRIPT_ANACONDA_USER} | su user
RUN bash /tmp/${SCRIPT_CLEANUP}
For example, preparing the Ubuntu image by installing basic commands is transfered into the script 01_ubuntu_sh
Hint: There are hardly any restrictions on the choice of names (variables and files/scripts). For the scripts, I use numbering to express order.
Since we will be working with several scripts, an exchange of information is necessary. For example, one script installs a package and the other needs the installation folder.
We will therefore store information needed by multiple scripts in a separate file: the environment file environment
And each installation script must start with a preamble to use this environment file:
#--------------------------------------------------------------------------------------
# get environment variables
. environment
Preparing Dockerfile and Build Environment
When building an image, Docker needs all files and scripts to run inside the image. Since we created the installation scripts outside of the image, we need to copy them into the image (run run them). This also applies to the environment file environment.
File copying is done by the Docker ADD statement.
First we need our environment file in the image, so let’s copy this:
#======================================================================================
FROM ubuntu:latest as builder
#--------------------------------------------------------------------------------------
ADD environment environment
Each block to install one required software looks like this. To be flexible, we use variable for the script names.
ARG SCRIPT_UBUNTU=01_ubuntu.sh
ADD ${SCRIPT_UBUNTU} /tmp/${SCRIPT_UBUNTU}
RUN bash tmp/${SCRIPT_UBUNTU}
Note: We can’t run the script directly because the run bit may not be set. So we will use bash to run the text file as a script.
As an add-on, we will be using Docker’s multi-stage builds. So here is the final code:
#--------------------------------------------------------------------------------------
# UBUNTU CORE
#--------------------------------------------------------------------------------------
FROM builder as ubuntu_core
ARG SCRIPT_UBUNTU=01_ubuntu.sh
ADD ${SCRIPT_UBUNTU} /tmp/${SCRIPT_UBUNTU}
RUN bash
Final results
Dockerfile
Here is the final Dockerfile:
#==========================================================================================
FROM ubuntu:latest as builder
#------------------------------------------------------------------------------------------
#
#------------------------------------------------------------------------------------------
ADD environment environment
#------------------------------------------------------------------------------------------
# UBUNTU CORE
#------------------------------------------------------------------------------------------
FROM builder as ubuntu_core
ARG SCRIPT_UBUNTU=01_ubuntu.sh
ADD ${SCRIPT_UBUNTU} /tmp/${SCRIPT_UBUNTU}
RUN bash /tmp/${SCRIPT_UBUNTU}
#------------------------------------------------------------------------------------------
# LOCAL USER
#------------------------------------------------------------------------------------------
ARG SCRIPT_ADD_USER=02_add_user.sh
ADD ${SCRIPT_ADD_USER} /tmp/${SCRIPT_ADD_USER}
RUN bash /tmp/${SCRIPT_ADD_USER}
#------------------------------------------------------------------------------------------
# NODEJS
#-----------------------------------------------------------------------------------------
FROM ubuntu_core as with_nodejs
ARG SCRIPT_NODEJS=10_nodejs.sh
ADD ${SCRIPT_NODEJS} /tmp/${SCRIPT_NODEJS}
RUN bash /tmp/${SCRIPT_NODEJS}
#--------------------------------------------------------------------------------------------------
# JULIA
#--------------------------------------------------------------------------------------------------
FROM with_nodejs as with_julia
ARG SCRIPT_JULIA=11_julia.sh
ADD ${SCRIPT_JULIA} /tmp/${SCRIPT_JULIA}
RUN bash /tmp/${SCRIPT_JULIA}
#---------------------------------------------------------------------------------------------
# ANACONDA3 with Julia Extensions
#---------------------------------------------------------------------------------------------
FROM with_julia as with_anaconda
ARG SCRIPT_ANACONDA=21_anaconda3.sh
ADD ${SCRIPT_ANACONDA} /tmp/${SCRIPT_ANACONDA}
RUN bash /tmp/${SCRIPT_ANACONDA}
#---------------------------------------------------------------------------------------------
#
#---------------------------------------------------------------------------------------------
FROM with_anaconda as with_anaconda_user
ARG SCRIPT_ANACONDA_USER=22_anaconda3_as_user.sh
ADD ${SCRIPT_ANACONDA_USER} /tmp/${SCRIPT_ANACONDA_USER}
#RUN cat ${SCRIPT_ANACONDA_USER} | su user
#---------------------------------------------------------------------------------------------
#
#---------------------------------------------------------------------------------------------
FROM with_anaconda_user as with_cleanup
ARG SCRIPT_CLEANUP=99_cleanup.sh
ADD ${SCRIPT_CLEANUP} /tmp/${SCRIPT_CLEANUP}
RUN bash /tmp/${SCRIPT_CLEANUP}
#=============================================================================================
USER user
WORKDIR /home/user
#
CMD ["bash"]
< function composerRequire1a366ea8c9013f37377c59393191f427($fileIdentifier, $file)
---
> function composerRequiref2da6e83b085fd96649a1eced6ba9cbb($fileIdentifier, $file)
vendor/composer/autoload_static.php
Changes
< class ComposerStaticInit1a366ea8c9013f37377c59393191f427
---
> class ComposerStaticInitf2da6e83b085fd96649a1eced6ba9cbb
You have three possibilities to add Bootstrap into your Larval Project
Methode 1: Adding Bootstrap by a Link to CDN
Using CDN (Content delivery network) is quite easy and simple for beginners. CDN is a network of servers providing the source files for almost every library used in front-end development.
We need the references for bootstrap.min.css and bootstrap.bundle.min.js
You add Bootstrap by inserting the following code snippets in your main Laravel Page.
In Laravel, all Frontend Modules are handles with Laravel Mix. This is an elegant wrapper around Webpack, a Package manager for installing and managing node modules.
To use Mix, you need to install NodeJS and NPM.
After this, install all required modules of your starter project
npm install
If you can see node_modules folder, this means npm is working.
Now we need to install bootstrap and the required modules
With the Bootstrap Framework installed, now we can style our Pages. An overview of what you can do could be found in the Documentation or using the Examples.
We will work with the Examples, so download all examples to the folder resources/views/bootstrap
With the Commandline and PowerShell, you could do this: Change to the folder and download the Archive with the examples
In this post, you will learn how to get started with Angular I18n using ngx-translate, the internationalization (i18n) library for Angular. We will cover the following topics:
setup new angular app
install required dependencies
add bootstrap as ui framework
create app with demo page and translation services
This will be the final result (click to show video). Source code for this post is on GitHub.
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { HttpClient, HttpClientModule } from '@angular/common/http';
import { AppRoutingModule } from './app-routing.module';
import { AppComponent } from './app.component';
import { TranslateLoader, TranslateModule } from '@ngx-translate/core';
import { TranslateHttpLoader } from '@ngx-translate/http-loader';
import { HomePageComponent } from './pages/home/component';
import { DemoPageComponent } from './pages/demo/component';
@NgModule({
declarations: [AppComponent, HomePageComponent, DemoPageComponent],
imports: [
BrowserModule,
AppRoutingModule,
HttpClientModule,
TranslateModule.forRoot({
loader: {
provide: TranslateLoader,
useFactory: HttpLoaderFactory,
deps: [HttpClient],
},
}),
],
providers: [],
bootstrap: [AppComponent],
})
export class AppModule {}
// required for AOT compilation
export function HttpLoaderFactory(http: HttpClient): TranslateHttpLoader {
return new TranslateHttpLoader(http);
}
How the app works
The translation is done with the ngx-translate component.
Translation works with different JSON files (for each language a separate file), containing the required translation for each text to be displayed. Each text is addressed with a name within the JSON file.
So, the base structure of each JSON file is the following:
Translation files
assets/i18n/de.json
{
"i18n-demo-header": "I18N Demo",
"header": "I18N Funktionalität in Angular"
}
assets/i18n/us.json
{
"i18n-demo-header": "I18N Example",
"header": "I18N Functionality in Angular"
}
These translations could be used in a html file by using the translate pipe:
bat is a cat clone with syntax highlighting and Git integration that works on Windows, MacOS and Linux. It provides syntax highlighting for many file extensions by default.
exa is a modern replacement for ls, the default command-line program in Unix/Linux for listing directory contents. exa supports icons with the --icons flag.
fd is a fast and user-friendly alternative to find, the built-in command-line program in Unix/Linux for walking a file hierarchy. fd provides opinionated defaults for the most common use cases. To find a specific file by name, you write fd PATTERN instead of find -iname ‘*PATTERN*’. fd is also extremely fast and it comes with a ton of options like ignoring hidden directories, files and patterns from .gitignore by default.
procs is a modern replacement for ps, the default command-line program in Unix/Linux for getting information about processes. It provides convenient, human-readable (and colored) output format by default.
sd is an intuitive find & replace command-line tool, it is an alternative to sed, the built-in command-line program in Unix/Linux for parsing and transforming text (). sd has simpler syntax for replacing all occurrences and it uses the convenient regex syntax that you already know from JavaScript and Python. sd is also 2x-11x faster than sed.
sed is a programmable text editor, with search and replace being a common use case. In that light, sd is more like tr, but on steroids. (thanks /u/oleid for the suggestion).
dust is a more intuitive version of du, the built-in command-line program in Unix/Linux for displaying disk usage statistics. By default dust sorts the directories by size.
ripgrep is an extremely fast alternative to grep, the built-in command-line program in Unix/Linux for searching files by pattern. ripgrep is a line-oriented search tool that recursively searches your current directory for a regex pattern. By default, ripgrep respects .gitignore and automatically skips hidden files, directories and binary files.
rip is an improved version of the rm command. It is faster, safer, and user-friendly. rip sends deleted files to a temp location so they can be recovered using rip -u. I really like the simplicity and the revert feature, as I don’t have to worry about accidentally deleting something using rm. While rip can be aliased to replace rm, the creators advise not doing that as you might get used to it and do rm on other systems where you cannot revert the delete.
tokei is a program that displays statistics about your code. It shows the number of files, total lines within those files and code, comments, and blanks grouped by language.
hyperfine is a command-line benchmarking tool. Among many features, it provides statistical analysis across multiple runs, support for arbitrary shell commands, constant feedback about the benchmark progress and current estimates and more.
zoxide is a blazing fast autojumper, intended to completely replace the cd command. It allows you to change directories without typing out the entire path name.
delta is a viewer for git and diff output. It allows you to make extensive changes to the layout and styling of diffs, as well as allowing you to stay arbitrarily close to the default git/diff output.
Tp-Note is a template tool that enhances the clipboard with a save and edit as a note file function. After creating a new note file, Tp-Note launches the user’s favorite file editor (for editing) and web browser (for viewing).
nushell is a new type of shell, written in Rust. Its goal is to create a modern shell alternative that’s still based on the Unix philosophy but adapted to the current era. It supports piping and filtering in a way similar to awk and sed with a column view so that you can combine operations like in SQL. (thanks /u/matu3ba for the suggestion).
xcp is a partial clone of the cp command. It is faster and more user-friendly with progress bars, parallel copying, .gitignore support, and so on. I like its simplicity and developer experience, especially the progress bars. I have aliased cp to xcp so I can use it everywhere.
zoxide is a smarter cd replacement. It remembers the directories you visit, and you can jump to them without providing a full path. You can provide partial paths or even a word from the path. When there are similar paths, zoxide offers an interactive selection using fzf. It is super fast and works with all major shells. I like how it works, and I have aliased cd to z so I can use it everywhere.
Hinweis: der Befehl startproject erstellt einen Ordner project, indem er einen weiteren Ordner project erstellt. Der erste Ordner dient dazu, sowohl das Django-Projekt, als auch die erstellten Anwendungen an einer gemeinsame Stelle zu speichern.
Der zweite Ordner project ist das Django-Projekt, in dem sich alle für das Projekt notwendigen Dateien befinden.
Wird in den nachfolgenden Beschreibungen vom dem Ordner project gesprochen, so ist immer der zweite gemeint (project/project)
Im nächsten Schritt werden die beiden erstellten Anwendungen (Core und Frontend) dem Django-Projekt hinzugefügt. Da sie in einem Unterverzeichnis (apps) liegen, muss ihre Konfiguration angepasst werden.
In dere Datei apps.py der jeweiligen Anwendung (apps/core/apps.py und apps/frontend/apps.py) wirr der Name angepasst:
Hinweis: Ohne diese Anpassung würde beim Start des Servers eine Fehlermeldung angezeigt
django.core.exceptions.ImproperlyConfigured: Cannot import 'frontend'. Check that 'apps.frontend.apps.FrontendConfig.name' is correct.
Im Anschluss daran werden die beiden Anwendungen dem Projekt hinzugefügt. Dies erfolgt in der Datei project/settings.py:
Im unteren Teil der Fehlermeldung findet sich aber eine hilfreiche Information:
Als erstes wir uns mitgeteilt, das ein gewünschtes Template in der nachfolgenden Reihenfolge gesucht wird. Es werden als (wir oben bereits erwähnt) mehrere Verzeichnisse durchsucht, um ein passendes Template zu finden.
Template-loader postmortem
Django tried loading these templates, in this order:
Using engine django:
Als erstes werden Verzeichnisse der Django-Installation durchsucht. Hierunter liegen z. B. die Templates für die Administration oder die Anmeldung.
django.template.loaders.app_directories.Loader:
...\lib\site-packages\django\contrib\admin\templates\frontend\index.html (Source does not exist)
django.template.loaders.app_directories.Loader:
...\lib\site-packages\django\contrib\auth\templates\frontend\index.html (Source does not exist)
Im Anschluss werden dann die Verzeichnisse unserer Anwendungen durchsucht.
django.template.loaders.app_directories.Loader: ...\project\apps\core\templates\frontend\index.html (Source does not exist)
django.template.loaders.app_directories.Loader: ...\project\apps\frontend\templates\frontend\index.html (Source does not exist)
Um nun ein gewünschtes Template zu finden, werden zwei Informationen benötigt:
der Name des Template
das Verzeichnis
Name des Templates
Der Name des Templates wird im View angegeben: apps/core/views.py:
class IndexView(generic.TemplateView):
module = 'indexView'
template_name = 'core/index.html'
Verzeichnis
Das Verzeichnis selbst wird über die Suchreihenfolge der zu verwendenden Template-Verzeichnisse ermittelt. Das erste Verzeichnis, dass das gewünschte Template beinhaltet, wird verwendet.
Ermitteln des Verzeichnisses
Im Falle unserer Anwendung frontend werden die nachfolgenden Verzeichnisse durchsucht, ob sie das Template core/index.html beinhalten:
Umgebung
Verzeichnis
Template gefunden
DJANGO
lib\site-packages\django\contrib\admin\templates
DJANGO
lib\site-packages\django\contrib\auth\templates
PROJEKT
project\apps\core\templates
core/index.html
PROJEKT
project\apps\frontend\templates
Template hinzufügen
Erstellen eines Templates für die Anwendung frontend: apps/frontend/templates/frontend/index.html
Weiteres Beispiel: Suchen des passenden Templates
Richten sie einen Neuen View in der Anwendung frontend ein: apps/frontend/views.py
class BaseView(generic.TemplateView):
module = 'baseView'
template_name = 'base.html'
Erstellen Sie eine URL für diesen View in project/urls.py
Wie zu erwarten war, wird das Template nicht gefunden:
In keinem der bekannten Verzeichnisse gibt es ein Template base.html.
Gemeinsame Templates für alle Anwendungen
Um Templates einzurichten, die von mehreren Anwendungen verwendet werden, empfiehlt es sich, ein Verzeichnis templates auf der gleichen Ebene, wie die Anwendungen, einzurichten
In der Datei project/settings.py wird dieses Verzeichnis dem Django-Projekt hinzugefügt.
Das zusätzliche Verzeichnis wird nun auch durchsucht:
Template-loader postmortem
Django tried loading these templates, in this order:
Using engine django:
django.template.loaders.filesystem.Loader: ...\project\templates\base.html (Source does not exist)
django.template.loaders.app_directories.Loader: ...\.venv\lib\site-packages\django\contrib\admin\templates\base.html (Source does not exist)
django.template.loaders.app_directories.Loader: ...\.venv\lib\site-packages\django\contrib\auth\templates\base.html (Source does not exist)
django.template.loaders.app_directories.Loader: ...\project\apps\core\templates\base.html (Source does not exist)
django.template.loaders.app_directories.Loader: ...\project\apps\frontend\templates\base.html (Source does not exist)
Erstellen Sie nun in diesem Verzeichnis (templates) das Template base.html
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
