Skip to main content

Posts

Showing posts with the label DevOps

Projects Ownership

Developers should be informed transparently about the next things that they are going to do since it impacts their mentality as well as their accountabilities. A view of Vung Tau beach First thing first, the Product Owner plays a very important role in understanding the business of the projects clearly and planning the User Stories for Development Teams. For Development Teams, we have two roles related to a project including Owner and Maintainer. The following are the definition and responsibilities for each role: Project Owner The Owner is normally assigned to the team that created the project at the beginning. It is known as the long-term project of the team. Therefore, the members of the Owner have almost knowledge of the projects including the history (i.e decisions made), business logic, and technologies used.  - Maintain a good system design (code) of the projects. Therefore, they are mandatory to review code (pull requests) from other teams. - Maintain the related documents of t

Awareness of Product Development

Software development can be understood simply as a program to receive inputs (i.e customer needs) and then produce outputs (i.e working software). It is worth it to know how many steps are in that program. When something gets stuck in a step, everyone is aware of that. The first painting of my son The General Process Big Picture There are two main factors in this picture including the people with roles and their interactions. All people involved in developing the product know their responsibilities clearly and how to make things done right. Therefore, a good collaboration can be reached. Product Roadmap Contribution It would be great for developers to know what the next features to work on are as well as when those features will be delivered. Therefore, the product roadmap is very important. The items in the roadmap should be contributed by ALL people involved in the product. Because software engineers directly develop, test, delivery, and monitor the software, they should also contrib

Automating deployment and managing apps on OpenShift

Previously, we maintained OpenShift templates for deploying apps in development environments as well as delivering these templates to our customers for their on-prem deployment. Customers who refer to our templates (as well as documentation) have their own configuration management tools to automate the deployment such as ArgoCD and FluxCD. My son's buildings Our developers usually modify templates (YAML) directly on OpenShift for testing and then adjust the corresponding templates stored in the Git repository in Bitbucket. This sometimes causes an issue that delivered templates are incorrect because: - Developers forget to update the templates in Git repositories. - Developers don’t test the templates Therefore, our goal was to integrate a tool into our CI/CD that can automate and manage the configuration of OpenShift apps. The delivered templates should be the ones that are able to run on our OpenShift with the following purposes: - Automate deployment from templated in Git repos

DevOps Toolchain Enhancement

 Historically, our company ubitec had started with a customer project. Agile/Scrum was our proposal for working with customers. Time by time, Agile/Scrum also became our culture for software development. To be successful with this development approach, we somehow needed to have a fast release for customers (i.e. every one week). Back then, we had a build tool Jenkins which was responsible for having sprint release packages for our customers. The build job pipelines contain some steps such as gathering the artifacts, checking the code convention, running the tests, building docker images, and packaging an archived file (a zip file). The set of tools involved in a pipeline is roughly called a toolchain. It is just a part of a bigger process called the DevOps toolchain. Source: https://www.ibm.com/blogs/cloud-archive/2016/11/devops-architecture-available-on-bluemix-garage-method-site/ DevOps is a proven method that fits Agile. Today,  it is even treated as a mandatory factor to have Agile

Safari (older than 14.1.1) rejects TLS connections of TURN with Let's Encrypt certificates

Summary We could not make a video call successfully on Safari older than 14.1.1. The call kept disconnecting for some seconds. We got the following error in Nginx’s log SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:SSL alert number 48   Root cause The Safari didn’t trust our TLS certificates (certified by Let’s Encrypt) when establishing a TLS connection into our TURN server. It is a known issue that could be found at Bug 219274 - ICE does not resolve for `turns` relay candidates rooted in LetsEncrypt CA . The issue was just recently fixed (end of 2020), therefore old versions of Safari still meet the issues.   Solution In our development environment, we replaced the untrusted certificate with a trusted one. We will warn our customers about this issue in our installation guide. Technical explained WebKit is a browser engine developed by Apple and primarily used in its Safari web browser, as well as all iOS web browsers. The WebRTC of WebKit relied on the upstr

Debugging the issue of using NFS shares for PSMDB on OpenShift

I have recently been trying to use PSMDB (Percona Server for MongoDB) as an open-source and free alternative for MongoDB Enterprise Server. I encountered an issue that the pod could not be initialized successfully with Persistent Volumes using NFS shares. I got the logs from the failed pod as follow: ------ ++ id -u ++ id -g + install -o 1000730000 -g 0 -m 0755 -D /ps-entry.sh /data/db/ps-entry.sh install: cannot change ownership of '/data/db/ps-entry.sh': Operation not permitted ---- I would like to share the steps how I used for debugging. The PSMD StatefulSet was deployed onto my OpenShift 3 OKD. Check the container mount info Go to a pod I could see the mount info as below mongod-data → /data/db read-write - mongod-data: Persistent volume claim name - /data/db: container mounted directory Check Persistent volume binding Go to the storage, I could know which persistent volume was bound to the corresponding persistent volume claim. Bound to volume psmdb-mongodb-data-0 Check P

PSMDB - A MongoDB alternative for having Encryption At Rest

Encryption is the most popular tool for securing data both in transit and at rest. - For protecting data in transit, we can configure to use the TLS connection - For protecting data at rest, we can use Percona Server for MongoDB (PSMDB), an open-source alternative for MongoDB Enterprise. License PSMDB Docker images follow the SSPL license. Therefore, it is not a problem when I only have my containers deployed in on-premises environments. Running MongoDB Replication on OpenShift I have successfully installed the replication by following the guide Install Percona Server for MongoDB on OpenShift . In order to make it work properly with my needs, I disabled some features from the default deployment. See the detail in this change Basically, I needed to create a CRD (Custom Resource Definition) to let OpenShift/Kubernetes what PSMDB is. Then, I deployed the Operator pod. Finally, I deployed the PSMDB StatefulSet. I used NFS shares for Persistent Volumes. Create CRD for PSMDB 2 git clone http