remove space

Days/CICD/Jenkins/Pipeline/Dockerfile

@@ -5,7 +5,7 @@ ADD index.html /www/index.html
 
 # EXPOSE $PORT
 
-HEALTHCHECK CMD nc -z localhost $PORT
+HEALTHCHECK .mdnc -z localhost $PORT
 
 # Create a basic webserver and run it until the container is stopped
-CMD echo "httpd started" && trap "exit 0;" TERM INT; httpd -v -p $PORT -h /www -f & wait 
+.mdecho "httpd started" && trap "exit 0;" TERM INT; httpd -v -p $PORT -h /www -f & wait 

Days/Monitoring/Elastic Stack/extensions/curator/Dockerfile

@@ -14,4 +14,4 @@ RUN install_packages cron && \
         >>/etc/crontab
 
 ENTRYPOINT ["cron"]
-CMD ["-f", "-L8"]
+.md["-f", "-L8"]

Days/day15.md

@@ -33,7 +33,7 @@ For one off jobs like installing applications or services you might need that `s
 
 ![](Images/Day15_Linux5.png)
 
-I find myself using `clear` all the time, the `clear` command does exactly what it says it is going to clear the screen of all previous commands, putting your prompt to the top and giving you a nice clean workspace. Windows I think is `cls` in the cmd prompt. 
+I find myself using `clear` all the time, the `clear` command does exactly what it says it is going to clear the screen of all previous commands, putting your prompt to the top and giving you a nice clean workspace. Windows I think is `cls` in the .mdprompt. 
 
 ![](Images/Day15_Linux6.png)
 

Days/day33.md

@@ -174,7 +174,7 @@ Azure PowerShell
 - Cross-platform PowerShell module, runs on Windows, macOS, Linux
 - Requires Windows PowerShell or PowerShell
 
-If there is a reason you cannot use PowerShell in your environment but you can use cmd or bash then the Azure CLI is going to be your choice. 
+If there is a reason you cannot use PowerShell in your environment but you can use .mdor bash then the Azure CLI is going to be your choice. 
 
 Next up we take all the theory we have been through and create some scenarios and get hands-on in Azure. 
 

Days/day38.md

@@ -22,11 +22,11 @@ This is where the details of the git repository are stored as well as the inform
 
 ### Staging Files
 
-We then start working on our empty folder and maybe we add some source code as a first days work. We create our readme.md file and we can see that file in the directory, next we check our `git status` and it knows about the new readme.md file but we have not committed the file yet. 
+We then start working on our empty folder and maybe we add some source code as a first days work. We create our readme.mdfile and we can see that file in the directory, next we check our `git status` and it knows about the new readme.mdfile but we have not committed the file yet. 
 
 ![](Images/Day38_Git3.png)
 
-We can stage our readme.md file with the `git add README.md` command then we can see changes to be committed which we did not have before and a green new file.
+We can stage our readme.mdfile with the `git add README.md` command then we can see changes to be committed which we did not have before and a green new file.
 
 ![](Images/Day38_Git4.png)
 
@@ -38,7 +38,7 @@ Next up we want to commit this, our first commit or our first snapshot of our pr
 
 We are going to most likely want to add more files or even change the files we have in our directory. We have already done our first commit above. But now we are going to add more details and more files. 
 
-We could repeat our process from before, create or edit our file > `git add .` to add all files to the staging area then `git commit -m "meaningful message"` and this would work just fine. But to be able to offer a meaningful message on commit of what has changed you might not want to write something out like `git commit -m "Well, I changed some code because it did not work and when I fixed that I also added something new to the readme.md to ensure everyone knew about the user experience and then I made a tea."` I mean this would work as well although probably make it descriptive but the preferred way here is to add this with a text editor. 
+We could repeat our process from before, create or edit our file > `git add .` to add all files to the staging area then `git commit -m "meaningful message"` and this would work just fine. But to be able to offer a meaningful message on commit of what has changed you might not want to write something out like `git commit -m "Well, I changed some code because it did not work and when I fixed that I also added something new to the readme.mdto ensure everyone knew about the user experience and then I made a tea."` I mean this would work as well although probably make it descriptive but the preferred way here is to add this with a text editor. 
 
 If we run `git commit` after running `git add` it will open our default text editor which in my case here is nano. Here are the steps I took to add some changes to the file, ran `git status` to show what is and what is not staged. Then I used `git add` to add the file to the staging area, then ran `git commit` which opened nano.
 

Days/day39.md

@@ -147,7 +147,7 @@ As an example let's go and delete our most important file in our directory, noti
 
 ![](/Days/Images/Day39_Git24.png)
 
-Now we have no readme.md in our working directory. We could have used `git rm readme.md` and this would then be reflected in our git database. Let's also delete from here to simiulate it being removed completely. 
+Now we have no readme.mdin our working directory. We could have used `git rm readme.md` and this would then be reflected in our git database. Let's also delete from here to simiulate it being removed completely. 
 
 ![](/Days/Images/Day39_Git25.png)
 

Days/day40.md

@@ -70,7 +70,7 @@ We can then drill down into the building block of GitHub, the repositories. Here
 
 As the repository is so important to GitHub let me choose a pretty busy one of late and run through some of the core functionality that we can use here on top of everything I am already using when it comes to editing our "code" in git on my local system. 
 
-First of all from the previous window I have selected the 90DaysOfDevOps repository and we get to see this view. You can see from this view we have a lot of information, we have our main code structure in the middle showing our files and folders that are stored in our repository. We have our readme.md being displayed down at the bottom. Over to the right of the page we have an about section where the repository has a description and purpose. Then we have lot of information underneath this showing how many people have starred the project, forked, and watching. 
+First of all from the previous window I have selected the 90DaysOfDevOps repository and we get to see this view. You can see from this view we have a lot of information, we have our main code structure in the middle showing our files and folders that are stored in our repository. We have our readme.mdbeing displayed down at the bottom. Over to the right of the page we have an about section where the repository has a description and purpose. Then we have lot of information underneath this showing how many people have starred the project, forked, and watching. 
 
 ![](Images/Day40_Git8.png)
 
@@ -176,7 +176,7 @@ Let's now make some changes, I want to make a change to all those links and repl
 
 ![](Images/Day40_Git27.png)
 
-Now if we check back on GitHub and we find our readme.md in that repository, you should be able to see a few changes that I made to the file. 
+Now if we check back on GitHub and we find our readme.mdin that repository, you should be able to see a few changes that I made to the file. 
 
 ![](Images/Day40_Git28.png)
 

Days/day41.md

@@ -14,7 +14,7 @@ When we went through the GitHub fundamentals we went through the process of fork
 
 ## Fork a Project 
 
-The first thing we have to do is find a project we can contribute to. I have recently been presenting on the [Kanister Project](https://github.com/kanisterio/kanister) and I would like to share my presentations that are now on YouTube to the main readme.md file in the project. 
+The first thing we have to do is find a project we can contribute to. I have recently been presenting on the [Kanister Project](https://github.com/kanisterio/kanister) and I would like to share my presentations that are now on YouTube to the main readme.mdfile in the project. 
 
 First of all we need to fork the project. Let's run through that process. I am going to navigate to the link share above and fork the repository. 
 
@@ -24,7 +24,7 @@ We now have our copy of the whole repository.
 
 ![](Images/Day41_Git2.png)
 
-For reference on the Readme.md file the original Presenations listed are just these two so we need to fix this with our process. 
+For reference on the Readme.mdfile the original Presenations listed are just these two so we need to fix this with our process. 
 
 ![](Images/Day41_Git3.png)
 
@@ -40,7 +40,7 @@ We have our project local so we can open VSCode or an IDE or text editor of your
 
 ![](Images/Day41_Git5.png)
 
-The readme.md file is written in markdown language and because I am modifying someone else's project I am going to follow the existing project formatting to add our content. 
+The readme.mdfile is written in markdown language and because I am modifying someone else's project I am going to follow the existing project formatting to add our content. 
 
 ![](Images/Day41_Git6.png)
 
@@ -74,7 +74,7 @@ Next we hit that contribute button highlighted above. We see the option to "Open
 
 ## Open a pull request 
 
-There is quite a bit going on in this next image, top left you can now see we are in the original or the master repository. then you can see what we are comparing and that is the original master and our forked repository. We then have a create pull request button which we will come back to shortly. We have our single commit but if this was more changes you might have multiple commits here. then we have the changes we have made in the readme.md file. 
+There is quite a bit going on in this next image, top left you can now see we are in the original or the master repository. then you can see what we are comparing and that is the original master and our forked repository. We then have a create pull request button which we will come back to shortly. We have our single commit but if this was more changes you might have multiple commits here. then we have the changes we have made in the readme.mdfile. 
 
 ![](Images/Day41_Git12.png)
 

Days/day45.md

@@ -58,7 +58,7 @@ The following table shows some of the dockerfile statements we will be using or
 | COPY       | To copy over files or directories from a specific location.                                                                                 |
 | ADD        | As COPY, but also able to handle remote URLs and unpack compressed files.                                                                   |
 | ENTRYPOINT | Command that will always be executed when the container starts. If not specified, the default is /bin/sh -c                                 |
-| CMD        | Arguments passed to the entrypoint. If ENTRYPOINT is not set (defaults to /bin/sh -c), the CMD will be the commands the container executes. |
+| .md       | Arguments passed to the entrypoint. If ENTRYPOINT is not set (defaults to /bin/sh -c), the .mdwill be the commands the container executes. |
 | EXPOSE     | To define which port through which to access your container application.                                                                    |
 | LABEL      | To add metadata to the image.                                                                                                               |