As of late, I took a dive at setting up and connecting WordPress with the database using container services. I created a website but couldn’t figure out where and how to deploy it. I was looking for a way with less exertion, at least expense, and minimum time. At this point, I thought of a SAAS product by Opstree Solutions called BuildPiper. I’d been wanting to try it for some time now and this looked like a good opportunity. Going in, I thought I’d have to go through the usual chores of using a new product, tons of documentation, hit and trial, etc. before I could get the hang of it. I wasn’t expecting a functioning website until at least the end of the day. But as soon as I had signed up, the onboarding felt like a smooth stream. I was able to deploy my site in less than an hour.
BuildPiper
BuildPiper gives the adaptability to set up applications with or without the manifest. On the off chance that somebody would not like to use the manifest, BuildPiper, additionally, gives a choice to create it using GUI, which is as basic as topping off a structure. BuildPiper is a powerful container management platform that automates and comprehensively simplifies the application delivery process. It is a unified container application delivery platform, that enables the dockerized code to be deployed to production immediately with all the required observability, security, and compliance baked in.
My experience with BuildPiper SAAS playground!
For me, I used WordPress as my container service which connects with MySQL containers in my setup.
For this application, I am using two Dockerfiles which are used to configure two different pods:
- WordPress application
- MySQL Database
MySQL database is a private service and need not be exposed publicly. Using BuildPiper, we can restrict and expose any pod/service inside our cluster. Therefore, I decided to create a private pod structure for the database and went on ahead to create and expose the WordPress pod structure publicly using the BuildPiper ingress feature.
BuildPiper gives the flexibility to use environment variables like setting up build & deploy environment variables. MySQL database contains some deploy environment variables like MySQL username, default root password, etc.
For WordPress containers, I am using a few build environments like WordPress username, password, database name, and database URL which I injected through BuildPiper.
Required Steps to configure/setup in Buildpiper Saas
First, we have to provide the service details for container service like
- service-name
- language supported by container service
- repository URL
- credentials detail
- build type
Now, we have to provide an environment type for microservice as BuildPiper supports multiple environments.
For the first part, we have to provide basic information about cluster and repository like
- the cluster, which is provided by BuildPiper in the playground
- the namespace associated with the linked account
- repository branch
- Dockerfile path for container application which is common for both services [ WordPress & Database ] in my case
The second part contains information about build variables and CI [ continuous integration ] information for service.
For my application, I provided build variables which are used by WordPress:
- Database
- Database username
- Database password
- Hostname [ Get from database service URL value ]
After setting up WordPress Build variables & cluster information for both WordPress and database setups, we have to provide resource Quota like CPU, RAM & replicas for different applications.
Now that we are done with that, we can provide access level information for our container application.
In this case, we need public access to WordPress containers through ingress routing. For this, we have to provide some information like:
- URL Name [ NAME.buildpiper.io ]
- Expose Path
- Service Port
For database pods, we need private access from our application. For this, we will choose private as ‘Access Level’ and provide the name/URL for the database along with the port which is used as build variables for the WordPress application.
Next is an advance level configuration which is based on Scalability [ auto-scaling ], runtime/deploy environment variables, vaults, liveness probe, and readiness probe.
We can either skip it or continue with the configuration to take advantage of advanced configuration options,
For our case, we only needed runtime/deploy variables for our database
- MYSQL_ROOT_PASSWORD
- MYSQL_DATABASE
- MYSQL_USER
- MYSQL_PASSWORD
Note: This is one time setup for each service & deployment and doesn’t take much time. Each service has its own interface where we can update/modify it.
After setting up both database & WordPress application services using BuildPiper, we can click on a service overview to view all services configured.
Finally, we have to Build & deploy to make sure everything is working fine.
We will first Build & deploy our database application as our WordPress application depends on the database.
To build database [ same for WordPress application ],
On pressing build, it will ask for the tag name [ optional ] and branch [ optional & default branch that we already set-up while configuring service].
The build will create a docker image from Dockerfile that is present in the repository path,
Once the build is complete, we can deploy the database pod from the built image. For this, we can click on the deploy icon and select tag as required.
We can setup the WordPress application using the same set of steps.
Now that we are all done, we can use our public ingress URL [ NAME.buildpiper.io ] which we provided during setup to access the website.
URL – http:/NAME.buildpiper.io
In the service dashboard, we can also check multiple things like
- Build & deploy status
- Latest Artifact name while building
- Current deployment artifact
- Commit ID & messages
- Build & deploy date
- Build by & deploy by
Cool, right? I wasn’t kidding when I said, “comprehensively simplifies the application delivery process.”
Benefits of BuildPiper Saas
- BuildPiper gives multiple ways to configure application deployment:
Build manifest with UI
Upload manifest file - CI/CD pipeline for single/multiple deployments
- Multiple language CI support
- Single click Build/Deploy
- Buildpiper also maintains build & deploy log history for each artifact
- Onboard a Dockerized service in minutes
- Setup & Run hassle-free secured Pipelines
- Enable the most robust & secure DevSecOps CI in a few clicks
- Single click service modification
- Easy interface to visualize the configuration
Know more about BuildPiper Saas & features
To set up the first containerized application on BuildPiper Saas, visit:
Opstree is an End to End DevOps solution provider