Python webdav client password#
We create the password file webdav.htdigest where the authentication realm the application is using is openshift-evangelists/blog-django-py. The web application, in this case, has been set up to use HTTP Digest authentication. To create a password file we run the command: htdigest -c webdav.htdigest openshift-evangelists/blog-django-py grumpy
Python webdav client code#
This is because we don't want everyone being able to access the source code over WebDav. Create a Password File to Authenticate Usersīefore we enable WebDav access in the Apache HTTPD server, we need to set up a password file to control access. Previously we would modify a local copy of the code files and rely on oc rsync -watch to upload the changes. oc set env dc/blog MOD_WSGI_RELOAD_ON_CHANGES=true This is done by setting the environment variable MOD_WSGI_RELOAD_ON_CHANGES to signal to mod_wsgi-express that it should monitor for code changes. In preparation for making changes to the code, we also need to enable automatic reloading of the application code when changes are detected. Visiting the URL for the web application, we are presented with: This is because we don't want others to be able to spy on our source code when we are accessing it. We use oc create route rather than oc expose, and we use edge as the option to oc create route, as we want to ensure we are using a secure connection when accessing the site. oc new-app openshiftkatacoda/blog-django-py -name blog To deploy our sample web application and make it accessible from the command line we can use oc new-app to create the build and deploy it, and then use oc create route to expose it and make it public. Let's move on to seeing how a WebDav enabled application could be deployed and used and then we can look under the covers at how the Apache HTTPD server is configured to enable WebDav access.
Luckily for us, the Apache HTTPD server supports being used as a WebDav server. In the case of our prior example, which was a Python web application implemented using the Django web framework, it was being hosted using mod-wsgi-express, which uses the Apache HTTPD server. To achieve this we will need a WebDav server to also be running in our container. In the context of the example application in our prior blog post where we used oc rsync -watch to perform live synchronisation of changes, if we could use WebDav to mount the original files from the running container on our local machine, we could achieve the same result without needing to run a separate synchronisation process. This means that one can connect to a WebDav server and then work directly with files hosted by the server as if they were present in your local file system. Although it relies on HTTP as the transport mechanism for communicating with a server, major operating systems support the protocol as a backend for mounted filesystems. WebDAV is an extension of HTTP that allows clients to create, change, and move documents on a remote server. Web Distributed Authoring and Versioning (WebDAV) First up, we will look at the WebDav protocol and using it as an alternative for handling live code updates to a running application. In this post we will start looking at how other more standard protocols might be used with OpenShift to handle file transfer.
Python webdav client download#
In the case of a different filesystem layout, you would need to first download a copy of the directories you want to work on from the container to your local filesystem, then set up the file synchronisation using that copy as the source.Īs much as oc rsync is useful for transferring files in and out of containers, it also is a mechanism specific to OpenShift and doesn't have support in third-party client tools users may be familiar with, for uploading and downloading files to or from other machines. One scenario where this may not work is where the building of the application image reorganised the original source code so that it didn't match the layout of the original in the local code repository, or a compilation process was performed as part of the build process. This was achieved only by making changes on your local computer, without having to re-build the application image, or manually upload changes each time. If the container was running a web server, or other web application which was able to automatically detect the updated file and use it, you could use this mechanism to perform live code updates in more or less real time.
This worked by virtue of the oc client monitoring the local filesystem directory for file changes and when they were detected copying the changed files to the running container, replacing the version of the file in the container. In a recent blog post we covered how you can use the oc rsync -watch command to perform live synchronisation of code changes between a local filesystem and a container.
0 kommentar(er)
