In the previous article, I mentioned how we can Dockerise a progressive framework based application (Vue). I have made few improvements to the application where I am now able to perform CRUD operations on the client side using AXIOS, based on API’s available from the server side. I wanted to test these incremental features added to the application and imagine executing those docker commands everytime you make a new component/feature available. This is quite a task. So I was looking at ways to automate the task where every time I commit/push the code to GitHub the build happens automatically so that the latest container is ready for deployment. This is where Docker Hub comes to our rescue. Here are the steps for the automated build process:
Now days with the adoption of Serverless architectures, microservices are becoming a great way to breakdown problem into smaller pieces. One situation that is common to find, is multiple backend services running on technologies like NodeJS, Python, Go, etc. that need to be accessible via HTTPS. It is possible to enable these internal microservices directly with SSL over HTTPS, but a cleaner approach is to use a reverse proxy that front ends these microservices and provides a single HTTPS access channel, allowing a simple internal routing.
In this blog, I am showing how simple it is to create this front end with Nginx and leveraging “Let’s encrypt” to generate trusted certificates attached to it, with strong security policies, so that our website can score an A+ on cryptographic SSL tests conducted by third party organizations.
In this post, I am going to show how to build and containerize a Vue.js application and let it run on Container Cloud Service (OCCS) using the following steps:
- Build a Vue.js Web App
- Build Docker image based on the above Vue.js SPA
- Push it on Docker-Hub
- Create a Service in Oracle Container Cloud Service (OCCS)
- Deploy Service (the vue.js app)
There are no shortage of acronyms in the security space, and shifting towards centralised-security, rather than perimeter-based-security, has added even more. As I have been playing with solutions around centralised identity services, such as Oracle’s Identity Cloud Service, I have found myself spending more and more time in IETF RFCs in order to understand these concepts. While there is a lot of value in the standards documents, they assume a lot of knowledge and I often found myself wishing for a slightly more approachable, high level description of the elements I was dealing with. While there is something tempting about being part of the secret ‘We read the security RFCs’ club, I resisted this, and took it upon myself to provide this higher level overview of these important concepts.
In today’s environment where systems run in the cloud and so much business and personal activity occurs online, passwords are not strong enough by themselves to protect applications. Scandals about password breaches seem to happen on a regular basis. It’s easy to find many case studies where passwords have been compromised as a result of malware, email scams and other techniques. The key point is that no matter how strong our passwords, no matter how much we educate our users, there will be situations where people are caught off guard and click on the wrong link, look at the wrong email or open the wrong document. Once this happens, our passwords can be compromised.