I am trying to find some guide or documentation that discusses best practices for setting up gitlab CI/CD to auto deploy a web server (nginx) / Centos or any Linux. Setting up the CI/CD as user root is easy, but i don't like the idea of having a root key in gitlab.
If i create a 'gitlab' user and assign it to the same group as NGINX, I am stuck because i can't CHOWN -R nginx to the folder and files once all the files deploy. So what are my options here? I suppose i could add the ssh key as user NGINX, but seems odd.
Are there any decent ways to do this?
Ideally, you would:
connect as nginx directly to make the installation
don't manage the private/public key through GitLab, but through a deployment tool like Ansible (see "How to use GitLab and Ansible to create infrastructure as code")
That way, no chown to do, and the keys are managed in Ansible, which knows how to connect to the target machines.
Related
I just installed bitnami/wordpress image using helm. Is it possible to sync it with git and when I will change some files in this git repository to update kubernetes pods?
I mean update Wordpress source code because Im modyficating plugins in wp-content/plugins dir.
You can use ArgoCD or Flux to automate this types of GitOps workflow. Check their documentation. They are pretty powerful and popular for GitOps in Kubernets.
A possible solution is to use git-sync in a sidecar container. It will periodically pull files down from a repository and copy them to a volume.
Here is a sample manifest which uses git-sync to update the content hosted on a simple nginx web server:
https://github.com/nigelpoulton/ps-vols-and-pods/blob/master/Multi-container-Pods/sidecar.yml
One way I managed it (although possibly a rookie way) was through github actions.
Here's an example of mine
And here's official docs from docker to configure with github actions
You basically want to tell github actions to recreate and push your image and then tell your cluster to refresh like so:
If you're using kubectl to manage your cluster check if your version supports kubectl rollout restart. You can use it to force any deployment to restart and smoothly recreate your pods (it also re-pulls the supporting image).
e.g.: kubectl rollout restart deployment/my_deployment
I want my dokku host to run the main nginx for my domain (let say cooldok.ku).
On cooldok.ku for some reasons I have other Virtual Machines serving content. I want to expose this content on a subdomain (say vm.cooldok.ku, runs in a VM at 10.0.0.7 on the cooldok.ku host).
I figured the involved methodology is called reverse-proxy.
In an optimal world, there would be a dokku-only way to register and 'link'/proxy the subdomains. As an added bonus, the cooldok.ku host would do the ssl-stuff for https itself (like ssltunnel) so that I could leverage existing certificates and/or use the awesome letsencrypt on the same machine and secure applications in the VM that were not meant to be served via https.
How can this scenario be realised with dokku? How difficult would it be to write a plugin doing that?
Update
So, basically dokku (0.8) comes equipped with exactly everything it would need. The question is, how much of what dokku wants to achieve (fire up those yummy docker containers) is in the way. To hack a setup which does what I want, following can be done:
# create folder where we want it
dokku apps:create vm
Now, these files have to be created/be present (vanilla 0.8 dokku installation)
#/home/dokku/vm/DOCKER_OPTIONS_DEPLOY
--restart=on-failure:10
#/home/dokku/vm/IP.web.1
10.0.0.7
#/home/dokku/vm/PORT.web.1
80
#/home/dokku/vm/URLS
# THIS FILE IS GENERATED BY DOKKU - DO NOT EDIT, YOUR CHANGES WILL BE OVERWRITTEN - I did it nonetheless
http://vm.cooldok.ku
#/home/dokku/vm/VHOST
vm.cookdok.ku
#/home/dokku/vm/nginx.conf
# Just listing changes from another default app
[...]
proxy_pass http://vm-host;
[...]
upstream vm-host {
server 10.0.0.7:80;
}
Afterwards, nginx needs a manual restart (or ... dokku can do something for us here)
I am pretty sure that some of the (redundant) information can be left out, as dokku should puzzle the nginx.conf itself, for example. I am not sure if this setup survives a reboot/nginx restart. Also, on tests, letsencrypt would not let me install the certificates/rebuild the nginx configuration because it sees the app vm as not being deployed.
Update2
To overcome the "app not deployed" issue, it suffices to touch /home/dokku/vm/CONTAINER, but this gets messier and messier ...
I bundled the information from the updates of my post into a dirty script at https://github.com/econya/scripts/blob/master/scripts/virt-helpers/fake-dokku-app.sh .
I guess the cleanest solution as-is with upwards compatibility would be to create a Dockerfile that launches a reverse proxy itself (configured via env/ config:set variables) - but I am happy to learn a smarter and nicer solution, or that I get paid to write a proper plugin ;)
Second approach would be to use a "Null"-Docker image together with a custom nginx template I guess.
Update 2021
According to the release notes it works now (look for "Routing to non-Dokku managed apps"):
https://dokku.github.io/release/dokku-0.25.0
I still use an older dokku and the solution written above, though.
I try to install Wordpress on the Swisscom CloudFoundry application cloud. To install it I need SSH with private and public key pairs (not cf ssh).
I follow the steps here:
https://github.com/cloudfoundry-samples/cf-ex-wordpress
Is this possible? What are the correct values for:
SSH_HOST: user#my-ssh-server.name
SSH_PATH: /home/sshfs/remote
Is this possible?
It depends on your CF provider. This method of running Wordpress requires that you use a FUSE filesystem (SSHFS) to mount the remote files system over the wp-content directory of your Wordpress install. In recent versions of CF (I can't remember exactly where this changed) you are no longer allowed to use FUSE based file systems.
Before you spend a lot of time on this, you might want to validate that your provider still allows FUSE. You can validate with a simple test.
Push any test app to your provider.
cf ssh into the application container.
Check that the sshfs binary is available.
Try using sshfs to mount a remote filesystem (man page | examples).
If you can successfully mount a remote filesystem via SSH using the steps above then you should still be able to use the method described in that example application.
If you cannot, the next best option is to use a plugin that allows storing your media on a remote system. Most of these are for S3. Search google or the WP plugin repo, they're easy enough to find.
There is a better solution on the horizon called Volume Services. You can read more about this here. I have not seen any public CF providers offering volume services though.
What are the correct values for:
SSH_HOST: user#my-ssh-server.name
This should be the user name and host name of your SSH server. This is a server that exists outside of CF. Examples: my-user#192.0.2.10 or some-user#host.example.com. You should be able to ssh <this-value> and connect without entering a password. This is so that the volume can automatically be mounted without user interaction when your app starts.
SSH_PATH: /home/sshfs/remote
This is the full path on the remote server where you'd like to store the Wordpress files. In other words, this directory will be mounted as the wp-content directory of your app.
I am just starting to get my head wrapped around continuous deployment with Jenkins, but I am running into some roadblocks and I haven't really found very many good, definitive resources on the topic in regards to ASP.NET applications.
I have set up a local build server than successfully pulls down code from a SVN repo, and builds it OK with MSBuild. This works well so far, but now I'd like to automate pushing this compiled code to a development server.
My problem is this - from what I gather based on what I read (which may be an incorrect assumption...) is that the staging server is typically within the same network as the build server, meaning you can share network resources, servers, etc.
In my case, I want to run the Jenkins server on a remote VPS, then deploy to other remote VPSes (so, essentially individual isolated machines communicating with each other).
I have seen alot of terms, but I am very new in my Sys Admin / DevOps type skills.
So, my question is this:
Is it even possible to, using Jenkins on a VPS, to then deploy to any particular server I choose? (I have full access to all of them, so if its a security thing, I can fix that... but they are not within the same network/domain)
What is the method to achieve this? I've seen xcopy, Web Deployment Packages (msdeploy), batch scripts, etc. mentioned, but not really a guidance behind what to use in what situations. Are any of these methods useful to achieve my goal?
Thanks for any help or guidance!
How is your Powershell? ;) You should check out psake.
psake is a build automation tool written in PowerShell. It avoids the
angle-bracket tax associated with executable XML by leveraging the
PowerShell syntax in your build scripts. psake has a syntax inspired
by rake (aka make in Ruby) and bake (aka make in Boo), but is easier
to script because it leverages your existent command-line knowledge.
psake is pronounced sake – as in Japanese rice wine. It does NOT rhyme
with make, bake, or rake.
You can deploy your files to the target server through SSH. Jenkins do support transfers through SSH. All you need to do is setting up a SSH server ex : CopSSH and a user account with admin permissions. and configuring the Jenkins to transfer through SSH.
Create host configurations in the main Jenkins configuration
Add an SSH Server
Add the public key to the remote server (the build server)
Click "Test Configuration"
Save
Configure a job to Publish Over SSH (Post Build Action)
Add Transfer Set.
Refer Publish Over SSH For More details
Can you throw some points on how it is a best way, best practice
to install web application on Unixes?
Like:
where to place app and its bases and so for,
how to configure to be secure and easy to backup,
etc
For example I know such suggestion -- to set uniq user for each app.
App in question is Jira on FreeBSD, but more general suggestions are also welcomed.
Here's what I did for my JIRA install on Fedora Linux:
Create a separate user to run JIRA
Install JIRA under the JIRA user's home directory
Made a soft link "/home/jira/jira" pointing to the JIRA installation directory (the directory as installed contains the version number, something like /home/jira/atlassian-jira-enterprise-4.0-standalone)
Created an /etc/init.d script to run JIRA as a service, and added it to chkconfig so that it runs at system startup - see these instructions
Created a MySQL database for JIRA on a separate data volume
Set up scheduled XML backups via the JIRA admin interface
Set up a remote backup script to dump the MySQL database and copy the DB dump and XML backups to a separate backup server
In order to avoid having to open extra firewall ports, set up an Apache virtual host "jira.myhost.com" and used mod_proxy to forward requests to the JIRA URL.
I set everything up on a virtual machine (an Amazon EC2 instance in my case) and cloned the machine image so that I can easily restart a new instance if the current one goes down.