When you are trying to update the JDK version 8 or 11 to JDK 17 and if you are using javax.xml.bind::jaxb-api then you will see the below error during the startup of the application
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) throws java.lang.ClassFormatError accessible: module java.base does not \"opens java.lang\" to unnamed module @5e922278\n\tat java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)\n\tat
the root cause is that the javax.xml.bind::jaxb-api is trying to use internal java API using reflection and the support is stopped from JDK16 due to the introduction of the "Strongly encapsulate JDK internals by default" feature.
Recommendation: The recommendation is to move away/upgrade the libraries that use reflection to load java internal classes
And the correct alternate for javax.xml.bind::jaxb-api is jakarta.xml.bind::jakarta.xml.bind-api
Or another way to resolve this is to add this java startup arguments option --add-opens=java.base/java.lang=ALL-UNNAMED
The flatten plugin from maven helps to remove any development-specific element, build specific element or environment-specific elements in the pom file and prepares a pom file that can be published and can be consumed by other
Service Account in K8S is used to invoke all the k8s admin server APIs within the POD provided the service account is granted with necessary RBAC permissions via role-binding or cluster-role-binding
The recommended way to invoke the K8S API from the POD is to use the official client libraries. However if we want to make a quick testing of service account configuration then we can use the K8S REST APIs to invoke and check whether the POD is having sufficient privilage to access the resources or not.
Before going to steps of invoking the REST API, few lines about how the POD gets that privilage. When a deployment/pod is binded with a service account, the POD will get the certficate, token and namespace in the location /var/run/secrets/kubernetes.io/serviceaccount
On executing the above command we would get the token I we can use to invoke the REST API, and now we can use the above token and form the curl command
If want to know what is the K8S admin API server IP etc, execute the below command to get it
$ kubectl cluster-info
Kubernetes master is running at https://147.154.106.173:6443
CoreDNS is running at https://147.154.106.173:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy
kubedashboard-kubernetes-dashboard is running at https://147.154.106.173:6443/api/v1/namespaces/kube-system/services/https:kubedashboard-kubernetes-dashboard:https/proxy
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
Ever wondered how to open the UI/GUI of the applications installed in a remote Linux server in our local development environment. Usecases like codebase is in remote server and we SSH into it to build the code etc and instead of using VNC to get the graphical interface, we can use this technique to open the applications installed in the remote server
The Datapump concept in Oracle database is very much useful for different usecases like taking backup, migrating the database from on-prem to cloud and more. Another advantage is it can directly push the dump into the OCI Object Storage
If we want to upload the dump into OCI object storage, we can use different authentication mechanism like authToken, basic credential based authentication, Resource Principal based authentication.
In this post, we will see how we can enable the resource principal and in particular how we can grant necessary roles to the non admin database user
Rarely we want our POD to talk to the kube-apiserver to fetch details about the other deployments, pod status etc. This is not a common usecase but the option provided by K8S can be used in a very creative way to solve problem when a running pod want to know information about the cluster
The logic is very simple, we use the ** kubectl ** command to talk to the kube-apiserver and access the cluster, the kubectl client maintains the details about the cluster in ~/.kube/config directory. And if we want to access the same from the pod then even the pod should contain all the configurations about the cluster so it can access the kube-apiserver
The good news is when kubernetes brings up the pod it mounts all the necessary folder that contains configuration, certificate etc and it will have one default service account attached to the pod. The default service account is authorized to access only a very limited resouce from kube-apiserver
We can create a new service account and authorize it to access additional resources by creating the following items
Ubuntu is one of the most popular free Operating System and it contains lots of packages which makes it ideal for day to day operation.
If we want to have ubuntu alongside the windows OS then we can follow these steps
Ensure we have a separate partition in HDD other than the one where Windows is installed for installing Ubuntu OS. If there is only one partition available in the system follow the steps in the link to create a separate partition
Adding additional tags to the image will be a common process in the CICD world, the additional tags would be something like the build number, test result, etc.,
When adding multiple tags it will be very heavy if we are doing the tagging locally and then pushing the tagged image to the server. So instead of doing like that, we can use the docker HTTP REST API which will be lighting fast tagging and will add the tag to the remote docker repository
Below is the example of tagging an image in a remote repository using python
defaddAssociatedTag(imageName, tag, associatedTag, bearerToken):
header= {'Authorization': ''}
header['Authorization'] ='Bearer '+bearerTokenheader['Accept'] ='application/vnd.docker.distribution.manifest.v2+json'res=requests.get(
url="https://docker.io/v2/"+imageName+"/manifests/"+tag,
headers=header)
print('Retrieved the metifests status is '+str(res.status_code))
# Add the associated tag by passing the same manifestsheader['Accept'] ='*'res=requests.request(
"PUT",
url="https://docker.io/v2/"+imageName+"/manifests/"+associatedTag,
headers=header,
data=res.content)
response_status=res.status_codeprint('Adding associated tag for '+imageName+':'+tag+' with '+imageName+':'+associatedTag+' is = '+str(response_status))
returnresponse_status
In the above, the setting the 'Accept' header is very important while getting the manifests. If we do not set it to 'application/vnd.docker.distribution.manifest.v2+json'then we will have the default 'application/json' which will not be correct when we use the content for adding the associated tags and we will get below error
Most of the time when it comes to docker, we play with using the CLI with 'docker' command. If we want to pull an image, tag an image, push an image we do all that with CLI only. However, apart from CLI, the docker repository supports varieties of REST API to do plenty of things and here I am planning to cover a few things like below
Manifest resource
The manifest rest resource can be used in a way how we want, for eg: if we want to know whether the image exists with a given tag then we can use the GET method of it
Maven is one of the very good build tools and is still popular among many users. Even though we use it for a long time, we use to remember or use only a limited number of its commands like 'mvn clean install', 'mvn package', mvn test' etc
we get to know many of its commands only when we face issues, one of the nice command is the 'mvn dependency:tree' to get all the dependencies including the transitive dependencies we have. In this blog, I am going to talk about this particular command
We should execute the below command from the folder where we have the pom.xml file
$ mvn dependency:tree
This will print all the dependencies from the root till the last jar, this will help to identify what are the transitive dependencies that we have.
We have varieties of options to fix the transitive deps error,
1. Add the transitive dependency into <exclusions> list
If you have control over the dependency then you can do one of the following
Kubernetes Secret are used to store secrets during the setup of the cluster and then we can mount the same inside the docker containers. In this example, I am using it to store the Oracle ATP wallet which is used to talk to the ATP instance
This is using the command line, apart from that even we can have a Secret Kind file similar to Deployment Kind and set it up using the 'kubectl apply'. After this, we need to mount the secret as a volume and use it inside the container
