Now I create a NGINX server as TLS termination proxy for the GitLab pages.
I only want to serve a small number of projects/groups and want to use Let’s Encrypt for the certificates. Together with my provider settings I’m not able to use wildcard certificates from Let’s Encrypt.
So I set up a dedicated domain for each group I want to serve and do not serve other groups.
You can run a docker registry either inside GitLab or use your own external docker registry together with GitLab where GitLab is only responsible to authenticate access to your registry.
I will describe in this article how to integrate an external registry with GitLab. The major problem that you encounter when choosing this setup is that there is no single description how to do this.
I had my projects hosted on GitHub and wanted to move this projects to my own instance. So after installing GitLab on my own server I started moving the projects.
Moving a project from GitHub to GitLab is quite easy. When creating a project in GitLab you have the chance to import a project from different sources. One of this sources is GitHub. For this the GitLab instance has to be configured to allow imports from GitHub (under Administration/Settings/Visibility and access controls).
I want to use the integrated CI/CD feature of GitLab so I have to install gitlab-runner as described in the documentation.
The installation does not need to be on the same host as GitLab — it is recommended not to do so.
After installing the gitlab-runner I register a runner with GitLab in order to use it.
After installing GitLab the next step is to configure NGINX as reverse proxy.
I add a reverse proxy because the NGINX server already runs for different services and I want to bundle all my services into a single web server.
Additionally this configuration gives me the possibility to use HTTP/2.
After a long time I will write some posts again. The first posts are independent of Java and the JVM but could be interesting to many Java developers also.
I decided to move my git repositories from GitHub to my own GitLab server. In this series of blog posts I will show how you can install your own GitLab instance and how you can configure it.
While working with files or streams there are many pitfalls on your way.
The first decision is: is the data binary or text?
If you have binary data the handling is straight forward:
InputStream is = ...
InputStream is the way to handle binary data.
But what if you have text data (e.g. a log file you want to read)? Then this is a job for a
If you now want to read a text the first try is
Reader r = new InputStreamReader(is);
But there is a pitfall with this approach as written in the documentation:
Creates an InputStreamReader that uses the default charset.
Reader is created with the default charset. When running on different platforms you will have different results. If you access an
InputStream that is connected to another computer (e.g. via a network) then you will likely be in trouble because you cannot expect a certain encoding.
To ensure to read the text clearly you must define an encoding and use this explicitly on both sides.
To open a
Reader with a certain encoding use
Reader r = new InputStreamReader(is, "UTF-8");
So you can ensure that the data is read with the defined encoding (UTF-8 in this case).
With this post I introduce a new category: Short Notes. I’ll create short posts about interesting parts of Java or recurring problems.
The start will be a post about formatting and parsing a
Date. This seems an easy task.
I had the job to implement the client side of a web service. To test this implementation I needed a server. I could have used a full-blown JEE server and deploy the server-side of the web service there. I decided against this approach (for several reasons).
Another solution for me would be to use the official test server for the web server. This was not feasible because the test server could be down for several reasons (leaving me with searching for bugs that are outside the scope of my duty) and the data was not reliable and changed regularly so that reliable tests were not reproducible.
I decided to deploy my web service as a simple web application to a simple web server (Jetty in my case). Also I wanted a simple way to deploy my test server/service so I decided to embed the Jetty server into a simple application which I can start with a simple script.
I had the problem to access a web service out of a Glassfish Application Server (3.1.1). Basically this is not a problem because Glassfish (and Metro – the JAX-WS implementation in Glassfish) can handle web services quite well. But in my case there where some problems accessing the web service. My problems were:
- The web service has to be accessed via SSL.
- The certificate should not be stored in a truststore.
- The certificate has not the hostname as the CN.
The first problem is not really a problem but with the second problem together with the first one can be really tough to solve. So lets solve this problems ;-).